I found myself in several discussions throughout the week regarding a web application under development and whether it should leverage an API that is being created.
Here's the situation. I have a PHP MVC web application with a MySQL DB as well as several mobile apps all being developed in house. For the mobile apps we're building a rest api. The big question is why should my PHP web application now use that rest api? I've always expected the use of an API to be for third party systems that need to interface with my database or for systems built on a different technology. The web app is certainly not a third party system and the services are in PHP. If the API is on a different server than the web app then I guess it could be considered a third party system... which has not been decided yet.
To me, it just seems strange to leverage the API for the web app especially since the APIs services are going to be limited to about 50% of the functions available in the web app leaving me to build the other 50% that would be unique to the web app. I also foresee a performance hit to the web app stepping through the service layer rather than just accessing the DB directly. On the other side I see more maintenance having a code base for my web app hitting the DB and similar functions built into the api for mobile apps.
Has anyone found themselves in a similar situation and can provide some technical pros and cons to why I should just use the API or can point me to a solid case study?
Pros:
What if one day you decide to move the backend app to another machine? With an API, your app code won't need to change.
What if one day you grow, and need to scale to 10000 backend apps instead of 1? With an API, your app code won't need to change.
What if one day you decide to swap out MySQL for Mongo? With an API, your app code won't need to change.
^ Enforced separation of concerns between data access layer (DB) and application
Cons:
More code up front when writing the app layer
More incremental work when you need to support a new app layer feature that your API doesn't support yet
To me, the pros clearly win.
Related
Using Laravel for PHP and DBMS. How do I make an app? (for social networking).
I have googled most of the things but I am really an Amateur and need help.
There are many kinds of apps, so before you start to work on your app, you need to carefully determine what exactly you need. You could write desktop apps for various operating systems, or native mobile apps, or hybrids, or a web application... You name it. Anyway, Laravel is the server-side and it should be as agnostic to the apps as possible. You need to create an API and handle the following things:
CRUD for the database
session (log in, log out, register, password change, user settings)
logical API functions
file transfer protocol usage
push notification (if needed)
As per your requirements, you will need to implement the server-side API in Laravel, which is a PHP-based framework and use an RDBMS, which could be MySQL, SQL Server, Oracle, or a NoSQL database, for instance MongoDB.
Before you implement any apps, you should have a proof-of-concept for the API. You should not invest too much time working out the details of the API, as when you are going to work on a real app, you will notice things to be changed anyway. The API should be accompanied by a playground for testing, maybe a very small app without design where you could send requests to the API. Or you can implement a WebSocket API to have a single, duplex connection. It is up to you.
As about how to write an API, there are many tutorials.
I'm building a mobile project that needs to be in constant communication with a server and i need some information . I know how to build local apps but this is the first time that i'm building an app that requires external call to a server / authentication service .
I'm asking for guidance how to proceed and which services/servers to use.
What type of server/database do i need ?
I'm guessing i will be requiring an API service but no idea how to choose/make one.
I want to use azure services/database but i also don't want to be dependent on it. I want to have my own url that i send request to and interact with a server/db that i can later move to another host fairly easily.
I develop websites mostly and i'm familiar with php/laravel + Mysql but i think in this case it will be overkill to create a laravel app simply for the server backend .
The app will be mobile only so i don't expect to have a webpage for it . simply an external server/database where the data will be saved.
First i need an authentication service - where each user will register on the phone which will then be saved in my external server/database . Then when they need to login - they will input the login details on the phone , which will query the esternal server/database and if validated - get their details from the server.
First, you need to decide which kind of server communication you'll need. it's in real time and constant? then you'll need a websocket. It's in bursts when you need to send or get data? then you'll need some kind of webservice (REST, RPC, SOAP). Then you have to evaluate the user load you'll have. And finally, the human resources you'll have.
Based on your question, I think a REST webservice will be more than enough. You may:
-Create a REST service for every group of related resources. Example: the /user URL should handle the signup, login, logout and user update operations.
-Create a method for each one of those operations and handle them. Then, call the method from the REST service class.
-Depending on the amount of users and the technology you're using, create a server to handle the requests, or upload your REST project to a server (tomcat, for example).
-Create an app and consume the REST services from there.
There are tons of tech you can choose for these things. PHP allows creating REST services, I think. Java is a very good choice too, since you can use the same code in both server and android apps. Node.Js is pretty popular, too, since you don't need servers and uses NIO (althought java can do both things using jetty and also has multithreading); golang and scala both have superb performance (golang is a lot more easier to learn, though, and it has no need to use external webservers).
Hope this helps.
For mobile applications the best will be REST (representational state transfer),becouse is lightweight and flex to use in other technology. I had project which include REST and mobile app and web app and it working very well.
In this scenario, we usually will build a REST API service for client end. As you are familiar with Laravel, you can refer to http://www.programmableweb.com/news/how-to-build-restful-apis-using-php-and-laravel/how-to/2014/08/13#apiu for how to build a REST API service with Laravel. Also you can leverage other light 3rd part PHP frameworks to build REST API service.
You can create and develop the application on local and then deploy to Azure Web Apps. Please refer to https://azure.microsoft.com/en-us/documentation/articles/app-service-web-php-get-started/ for more info.
And there several vendors provide MySQL services on Azure. ClearDB is a BaaS on Azure for MySQL. You also can use the VM to host your MySQL Service. E.G. MySQL by Bitnami and MySQL by Docker.
I want to create following project :
Server application hosted on Azure - it connects to databse via Entity framework and gives and API for anyone who want to connect (but with account stored in SQL database)
WPF application - it consumes server methods, objects etc.
Web app (php & javascript) - also consumes server methods and object etc.
IMPORTANT : I have only azure student's subscription and I want to hold onto it - buying anything else is out of the question unless it has strong argumentation.
I figured that to do this I have to create REST Web API because I have no other choice to connect to server than via HTTPWebRequest (because I want to have the same API for WPF nad web app).
My question is : does better solution exists?
I think I can create different API's for desktop client than web app but I have no idea how to do that. Whould you be so kindly to show me other way?
Why dont I want to have this solution?
Reason is simple. For big databases and slow internet connection it would take ages to download whole data in few seconds. As far as my knowledge goes there is no lazy loading in REST thus my WPF application's thread reponsible for downloading database would freeze for a big period of time.
If my question is too broad please leave a comment before you put up a flag.
Also, any tips regarding my project design are well appreciated.
Different APIs for Desktop and Web: this can be done easily enough. Assume you have a class library to contain your business logic (domain stuff). Create a web api project that makes use of it, then create yet another web api project separately that also makes use of the core models. When you deploy, deploy each separately to a different domain/subdomain (I'm unsure if you'll require further Azure resources for this, but consider api.desktop.myapp.com and api.web.myapp.com... no real technical reason why you can't do it that way, though for architecture reasons I'd avoid it (it's really coming close to if not definitely is duplication of code).
Same API for Desktop and Web: you stated that you thought you'd have to do this differently for the desktop and web, specifically because of the resource usage on the server. I disagree here, and think you should implement some standardized rate limiting into your API. Typically this is done by allowing only X amount of resources to be returned in a single call. If the initial request asks for more than X limit, an offset/nextID is returned by the API, and the client submits a new request noting that offset/nextID. This means you have subsequent calls from the client to get everything it needs, but gives your server a chance to handle it in smaller chunks (e.g., check for rate limits, throttling, load balancing, etc). See the leaky bucket algorithm for an implementation that I prefer, myself: https://en.wikipedia.org/wiki/Leaky_bucket)
For implementing a real-time application in Laravel like Gmail or Github, in which all things (such as opening new page, sending mail, inbox, submit forms and etc) occur in one page, I did a lot of research and found that I should use Laravel Pusher package. But I think it is not free for large projects.
Also I read https://www.codetutorial.io/laravel-5-and-socket-io-tutorial/ article (and many other articles) that uses redis with NodeJs.
Regardless of Laravel Pusher, my Question is what is best and usual way to implement real-time apps via Laravel?
I am using Laravel 5.2
As #gurghet pointed out, there is a difference between a SPA and a realtime application. Gmail is indeed a real time application instead of a SPA.
API Comes first:
If you are looking into creating REALTIME Applications, then first of all you have to create an API (REST/SOAP). Laravel and Lumen both provide an excellent code base to start your api in no time.
Choosing the right JS framework:
Once you have an API, you will need a JS framework. When it comes to REAL TIME applications, there are just a hand full of frameworks that will give you true flexibility. Angular being on the top, followed by REACT, BACKBONE and meteor.
Angular has lots of fan following/community, so it should be the appropriate choice.
The Perfect PHP Stack:
Laravel + Angular stack is great. Laravel is very flexible so you can do almost any kind of server side scripting with it. It also keeps on inspiring you to write cleaner code each time. While angular is very good with 2 way bindings. Which means that when you pass the same data to a view in different places, angular keeps track of all the changes made to the data. It also has features like PROMISES, where angular doesn't wait to get real data from the db, instead it just assumes that the data should have been updated to the db and just shows you the changes (the ones that it keeps track of) in real time.
The Authentication: The most frustrating part of the whole process, is securely authenticating users i.e passing data from angular to laravel. You will have to use OAUTH or JWT for authenticating users. Although both have been around for a while, but you wont find any good code/guides regarding authentication. I have spent lot of time here, but you can always purchase some bootstrapped / properly configured projects on codecanyon.
Sockets are the key:
No Real Time system can exist without sockets, you cant just keep hitting the db on regular intervals to check for updated values. Here sockets save the day by informing the system that updates are available, upon which you can grab the updated values from db.
Now a days services like pusher, have solved most of the problems and laravel also comes with a built-in api-client for pusher. But you are always free to use opensource softwares to create your own socketing system eg. socket.io.
What you are calling real-time apps are really called single page applications or SPAs. Real-time applications are things such as software for airplanes, trains and stock exchanges.
If you want to create SPA you don't necessarily need pushing services. I would suggest you to take a look at these front-end projects:
Angular js
React js
Vue js
I have a website and am planning to develop a mobile version of it for the iphone, blackberry and android.
My website is a social network built on PHP Zend framework. Now all these mobile apps are going to be having the same functionality like the website.
I am little ignorant about this - but from a high level I understand that all these mobile apps should not have to write any backend logic. For every functionality - they will simply make a web service API call to interact with the backend.
So does that mean, for every functionality I need to create a web service method. Can the existing code be re used - I'm a little lost -
Can someone shed some light on this matter or point me in the right direction (like some articles)
Thanks
I think the best thing for this kind of application would be write a mobile website. This should not include more than some new views in your Zend framework application.
There are some tutorials out there how to start. Just use your favorite search engine.
Apple and Android have browsers which are very advanced. They actually show the site in total. The point is would your website look better in that interface? ( I bet it would be cumbersome). You would have to make a mobile site (as suggested by #Felix) and implement the required features in a simple interface.
If you want an installable application then you are looking at three applications(one for each platform). My suggestion would be to make the mobile site and look for an app maker kind of product which would install your regular mobile site as an application on these platforms.
HTH
This is a very open subject that's obviously going to divide opinion (as already demonstrated it seems! :))
My personal view on it it this, using Safari on my iPhone is a terrible clunky cumbersome experience and "mobile optimised" websites are not ideal and don't really take advantage of the features of the device you are developing for (i.e. multi-touch etc)
This is why I think mobile applications are more appropriate ways of encapsulating the content of the web and delivering in a format suitable for its platform. Take for example, the Facebook application for iPhone and Android. That's a perfect example of taking the core features of the website and contextualising it in a manner that's easy to use and designed from the ground up for the device it's made for.
In answer to your question then yes, I would approach the development with web services in mind and use these to feedback the relevant data you need to interface with your site
While I agree with djhworld that the native mobile applications are sometimes easier to use than mobile-optimized web apps, there is a pretty big gulf in implementation time and user base fragmentation. I think the best first step is to develop a mobile web application, and if you are getting use there, consider developing native apps using web services. You may also want to look at PhoneGap as a way to cross-compile a single mobile app:
http://phonegap.com/
Also, see my other post about mobile web application development.
If you want to maximize your investment in your mobile site, I would develop it in HTML5. Currently, only WebKit browsers support it (iPhone/iPod/iPad/Android/Blackberry[soon]), but within a year most devices in developed countries will support it.
If you need to detect mobile devices on the server side, I would recommend Tera-WURFL. It is a high-speed PHP & MySQL mobile device detection software package that is free and open source.