I'm creating a website in PHP and mysql. I plan to create a native smartphone app for it in the future. The app will allow users to interact with my website's database and receive notification when new data is posted to their accounts. What should I implement in my website while anticipating a future mobile app for it?
I have been creating the same type of system for a few customers of mine. I have built them a website where there customers for example, make a hair cut appointment, that then sends a notification to the hair stylist notifying them of the new appointment information. Is this something similar to what you are looking for?
Also if so, i need to know what language you will be coding the phone app in. I suggest using Java if your going to be learning a new language to do this.
As for needing to implement anything prior to actually creating the mobile app. Thats not necessary.
When you create your native app, you are going to want to access your business logic and database via an API that you create. So when you are developing your website, you really want to think in terms of a MVC (model-view-controller) architecture. Ideally, both your website and mobile app will share the same model and controllers, and you will simply implement the views (very) differently in each.
For example, when you do a login on the website or in the app, you want it to call the exact same code base on the server (and pass the exact same parameters) to process the login. Therefore, make sure to decouple your business methods (controller logic) from your presentation layer when you design the site and always think in terms of "should this functionality be exposed in my API or is it website only presentation".
If you do this now, it will save you a lot of pain later.
Related
I have to prepare a specification to provide a road-map for developers to build an in-house project.
The project will consist of a web application and a mobile application.
The mobile app will be used to collect user feedback, typically the mobile app shall display a couple of questions for the user to answer.
Example questions show below;
Did you use shoe polish to clean your shoes ?
Did you watch the news at night ?
The data captured will be sent to an sql server.
The web app shall be used to publish the questions to the mobile app, the web app shall also be used to view reports.
The web app shall have below features;
1. Publish surveys to the mobile app, this could be done by MQTT,AMQP or similar protocol.
2. View data in chart form
3. Manage devices, like enrolling new mobile devices e.t.c
What is needed
This project will be spit and assigned to 3 teams, the backend team(Api team) , the frontEnd team and the Mobile developers team.
The functionality of the backend is supposed to go into an Api, the front end should always talk to the backend for getting data, basically no business logic is allowed to go into the front end side of things. The front end will only write css/html/js for markup & presentation, the rest of the functionality should be consumed through an Api.
I have to write a detailed specification of how the project should be implemented, the back-end will be implemented in PHP with symphony. The front-end can be any JavaScript framework, the mobile app will be implemented in Android.
Can you should how i should model the back-End(Api) so that it contains all the functionality needed in the web app ?
On top of that, building the functionality on top of an api a good strategy for this project? Should i go the monolithic way as having the front end and back-End attached together(this will make it difficult to have one developer working on the front end and another one on the back-End/api ) ?
This is a perfect application for a CQRS back end, fed by a queue. With CQRS the write side and read side of the back end are separated into distinct APIs which is especially advantageous when splitting a project among multiple teams.
The main idea of CQRS is that there is a single API to make any changes to data, and changes are made to data via a Command, then persisted to the normalized DB by the Command. There are also physical tables custom designed to contain all data necessary for a single view (these tables are denormalized). Each time data is written to an Aggregate, the appropriate View Models are also updated. This results in a structure where the write side is complicated but has all business logic and rules, whereas the read side is very simple and basically just executes a “select *” query from the appropriate view model table. As long as the read model (also called a projection) is kept up to date the reads are much faster and since the majority of the DB access is reads, the entire site is faster.
In your case I would create 3 APIs – one for the Read Model for the Mobile front end, one for the Read Model for the web front end, and one for the Command side. That way the mobile guys have the flexibility to build what they need, and they can change the read model table design as necessary during development to satisfy requirements. The Web guys can do the same, and the Backend team implements the hard stuff – the commands, business rules, normalized table structures, etc. Merging the three projects would entail having one of the teams create queries to update the view model tables from the entity tables.
All this becomes even easier if you introduce an event based communication architecture, i.e. Event Driven Architecture. This would further decouple the 3 different concerns and make them even easier to merge later since each microservice would subscribe to appropriate messages to receive updates and new cache information.
We are building a intranet web application in PHP with CakePHP.
However we have barely experience with CakePHP
Our Intranet will have two user portals.
Employee portal
Client portal
Both portals will use the same data but have their own user interface.
Employees can see other data than clients and vice versa.
We want to build a central core for both portals. For example, a single authentication system, a contact form, a notification functionality, same footer information, etc. We want to use this central core as much as possible so we don't have to rewrite code.
We use Git to manage our code. We want to make a branch for both portals and one for the shared core.
We hope you can give us some advise about how setting this up with CakePHP.
Is building multiple app's a good idea?
Or should we just run CakePHP and our core on two web servers? (one for each portal)
Or should we use plug-ins for the core functionalities?
Or should we use single controllers with multiple views (one for employee and one for client?)
Or something totally different?
Thanks for any advice
Eventually, you'll start noticing similarities between the 2 portals, and the code-base. If they are sharing same data, why don't you have a single code-base and have permissions around what users can see based on roles? We had to do this recently when we merged 3 pages into 1. 1 page was for admin, and the other 2 was for other roles. Then users started requesting features on page 2 that page 1 already has etc etc. it became a mess and we decided to consolidate these pages into 1, and have permissions around what each users can see based on their roles. Also read more about helpers as it will come handy, so you dont make your view bloated.
In my experience a portal is typically a very thin layer on top of some CRUD framework. I think the opportunity for code sharing between these two applications is very limited. You can share the authorization and authentication .. and that's about it and I don't know if sharing this part is a good idea (probably not).
If most of your code goes into building the HTML views you'll likely end up with two completely separate views for employee and client.
As Ayo mentioned... the permissions alone will separate the two user groups and you can take advantage of CakePHP's layout or the themes feature to give a totally two different look for each user group.
You may also want to take a look at CakePHP plugins feature. It allows you to easily add new functionalists to an existing app, without messing with the existing code base.
My web development experience has mostly been setting up a CMS like Wordpress or Drupal and creating custom themes. Actually work in server-size coding has been very minimal. I've played around with php a little, trying to mod off of phpBB and beginning to learn some MVC work with CodeIgniter. Overall, this seems like a pretty big step forward, but it's something I need (I think) to do for a project I am working on.
Essentially what I want to do is have a service like Twitter of Facebook (not in the social networking sense); a user is able to log into the site and perform various operations, while also being able to use an android application that supports limited operations.
After some Googling and reading articles on the internet, it appears REST is the way to go. But I can't quite seem to grasp some of the technical details. I understand how the HTTP Request/Response works, but I don't know how I can code everything server side so that visiting example.com/item/1 will bring up the details of item 1 in the browser and can also perform a GET Request in my Android app so it can grab the details from the database and display in on the site.
Any suggested readings or some tips on how to execute this?
You can implement this using MVC. By default, have the controller ask the model for the details of the item, then pass the info to the view. Repeat this process for each type of request you want to accept such as POST, PUT etc., where you define a new function in the controller, ask the model to perform the corresponding database action, and return the response to the view.
There is helpful tutorial for getting a REST server up and running using CodeIgniter here
I have different questions about a full architecture idea. I hope someone with great experience could help me out because I am pretty much getting stuck in all possibilities.
I'm planning to rewrite a community website. Our customer wants to make use of native mobile apps in the future. So I will need to take this into account. Because of this I have decided to create a 100% REST API architecture based on the PHP framework Kohana. I have choosen Kohana because this makes scaling the internal API to a other server very easily without much extra effort. (Kohana threats internal url requests not as HTTP so there isn't much overhead in the beginning and can scale to HTTP with some minor code changes).
At first the API will be private, but later on we might make it public to let more services connect to us easily.
De basic REST structure is as follow:
/cats
/cats/1
/cats/1/custom
'custom' could be 'childs' for instance.
same goes for:
/ads
/bids
/users
/banners
etc..
These are perfect entities for the API because the mobile app will definitely use all this functionality.
So we can conclude the core of the website is REST. So basically I want to make the website a client of the API just like the native app in the future. This way maintenance seems much easier.
What worries me though is the fact that there is much more than this (managing uploaded files, invoicing, automails for invoicing, automails for ads and so on). Uploading files needs to go through the website to the API. Is this common practice? If I do not do this, the website would do upload logic, which makes the site no client anymore and the app itself. Hence the mobile app can't even upload and both API and website need to know the upload folder (duplicate logic).
I thought of creating the following modules:
community-api
community-website
Api seems to be the core then. But.... what about cronjobs etc? Actually they should not be part of the website, as this is just a 'client'. I feel they should interact directly with the model or API. So basically the API gets more like a gateway to the core and thought I need this:
community-core
Models
Cronjobs
Auto Mailings (part of cronjobs)
Invoices etc
community-api
Interact with models in core through HTTP
community-website
Website
Admin
The core cronjobs are a exception to the REST structure. They are the only one that can change data without going through the api. At least that was my idea because they belong in the core and API is on top of the core.
But by design that seems just wrong. Manipulating should only go through the API!
Alternative:
community-core
Models
community-api
Interact with models in core through HTTP
community business
Cronjobs
Auto Mailings (part of cronjobs)
Invoices etc
community-website
Website
Admin
This look better by design to me.
(source: mauserrifle.nl)
Main Questions
1)
Should cronjobs manipulate through the API or Core models?
2)
My invoice cronjob needs a template pretty much the style of main website of course. But if my cronjob is part of business or core it won't have knowledge of my main website. What makes sense to solve this?
3)
My website will be using mustache as a template engine. (both php and javascript can parse these templates). I thought using the api directly for ajax calls but then realized:
The site gets data from api, formats timestamps to dates (Y-m-d) for the template and then renders. If I let javascript call the api directly, javascript must have logic too (formatting). This is duplicate code! Feels like the only solution is calling the website for ajax (which calls the api and formats) and returns the formatted json. Am I right?
But.... simple calls like deleting a ad can go through the api directly (e.g. DELETE: /ads/1
I get a mix of calls....
Any better solution for this?
4)
Overall: Is my architecture too complex? Any alternatives I should consider?
I would love to hear your feedback!
Once I've heard that a good way to develop a web application is to develop an API-Centric Web Application. The thing is, to me, if you couple the main service to the public API, building an API-Centric application, you lose the whole point of developing a public API at all.
This doesn't seem logical to me.
Yes, the API and the website and what ever might come next are separate things and website should be a client to the API itself but since it will simplify things greate, I believe that you should RE-USE the domain-classes to build and base your web-site logic. This way you can use all the same code base and handle all your issues including ads, invoicing and of course file uploads with ease.
For the public API, it should be on a separate box if possible re-using the same domain classes but with different authentication methods so that whatever problem might occur, it won't affect the main service.
Your cron-jobs should only be used to fire the call through the API itself and those calls should be made on the main app (website through the API)
If you build your website without repeating-yourself, as in, using the same code as the base and wrapping the web-app around it, you won't have the issue raising in q#2.
Same thing applies for question number 3. If you wrap the website around the API, the website can use the api itself without being a separate entity.
Your architecture seems complex but if you do these things, it will be simple. ;-)
Good luck!
REST is just one way to initiate a request. Your core code that processes the request shouldn't be tightly coupled to the REST interface, or HTTP for that matter. I would advise designing your REST API as a simple mapper to an include file or something similar. Your cron could then bypass the whole REST API and just include the file directly. Separate the request interface from the code that does the actual processing.
I have a small web app written in php / mysql that stores customer information and does various things with it.
One of my users has expressed interest in integrating my app with the custom software (also web-based) that they use for setting up customer appointments.
Basically they want a system where, when they create a new customer account using their online software, that information is automatically relayed to my application, to create the customer account on my end as well. This would save them having to enter the same information twice.
I am wondering what your suggestions are for the easiest way to approach something like this? Do I have to create a full-blown RESTful API? (I have never done anything like that before and am not really sure where to start with such a thing.) Or is there a simpler way?
Any ideas or suggestions would be much appreciated. Thanks (in advance) for your help!
In order for another application to communicate with yours, you will have to create some type of API, whether it be RESTful or not.
Personally, I recommend REST as it is fairly trivial to setup and there are LOTS of tutorials on the internet to show you how. If you use Zend Framework, it's 10x easier as they have a REST controller you can extend and quickly build an API with.
Something very simple, which has worked for me is to simply accept the information as a POST. The other application will send the information via POST, which you process in your php, and store it in mysql. if the data is sensitive, you can set up a cert and go over ssl.