I have a ZF1 project that was developed used the lean startup approach. I'm now ready to move into a more evolved project as I know what my users want, but I really want to develop using better techniques. I've decided to move from ZF1 to ZF2 for support reasons and this is where I'm at:
API(Client) - I have a "push only' API that users use to send me data
API(Admin) - The admins can consume the data pushed using a variety of metrics and aggregates
The API for clients is restful but just pushes into a Redis job queue currently and is processed via cron. This removes the need for clients to wait for their data to be inserted and their requests are returned immediately.
The API for admin is currently not restful and is actually consumed inside of the application only. I think that this is okay as I don't want to have a single page frontend or API consuming front end. I would rather data be returned immediately by the server.
This leaves me with the question of whether I have an API Service Module which provides all of the Models (Doctrine2 ODM POPOs), mappers, filters, and a service layer to access it all and then the controllers that need it can consume the API without making HTTP requests (via service calls).
Is this the proper way to structure or is there a more refined and acceptable approach? I like the service layer in general as testing will be more accurate and all clients / admins are using the same API (if it updates it is essentially updated immediately across the board as there are not separate projects).
I think the module you think of doesn't need to have an own built service layer which only forwards to another service (like Doctrine entitymanager or something else), it rather should only provide the other modules the required services by configuring the DI and encapsulate the required classes (like models, mappers, filters, ...).
In my company for this purpose there is always an 'Application' module (like it was in the early tutorials of ZF2). I dont know if this is still best practice, but there are some serious benefits regarding maintainance and structure.
You should consider defining a module dependency in the 'consuming' modules (like Client-API or Admin-UI).
It is also worth to take a look at the Doctrine library and DoctrineModule implementation, to get a feeling what a module should provide and where it makes sense to only provide a library.
Related
My main application is being built with Vue (mydomain.com), I also have a REST API (api.mydomain.com) and then my assets (assets.mydomain.com).
The API is unlikely to be used by other developers, and is only for my convenience when building the spa with Vue. Considering this: would it be better to build a single Laravel application that handles all three subdomains OR have a Laravel application that handles the API, a standalone Vue build for my main application and then serve the assets as a seperate build entirely?
What are the pros/cons for a single build vs three?
I haven't used Laravel in that context but I sure prefer the more modularized approach of having different builds for different functionality.
I normally use the approach with Node.js where I have both assets and api handled by the backend. (Express app etc) and then separate build fetching the data to render in the spa using React.
This build benefits scalability since you can easilly maintain, track and debug the code. Obviously it makes it also easier for unit testing. And the performance of the SPA isn't affected by the payload routing in the backend since it runs separately and only interact upon request (REST API in my case).
I hope I provided useful insight.
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.
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
This is a very general question, however I have done some research and believe I am simply missing some useful terminology of the concepts in question, and if someone could point me in the right direction it would be helpful.
Basically I am creating a PHP page, that will send a request - this will then be received by a native app. Where the user will either accept or decline the request. This will then be sent back to the PHP page.
So my queries..
What technologies or key concepts need to be applied here..
Main areas
-- PHP to send request
-- Native app to be listening for requests
-- PHP to be able to listen for the response
-- All needs to happen in real time i.e. user requests service, administrator confirms/declines, user receives response. All within in est. 60 seconds.
If you want to go into the right direction and you want all this to be on PHP, I would look at PHP RESTful service. Maybe
read up on this resource: http://www.amazon.com/RESTful-PHP-Services-Technologies-Solutions-ebook/dp/B005VQ8SB6/ref=sr_1_1?s=books&ie=UTF8&qid=1419012976&sr=1-1&keywords=9781847195531
You can also look into Symphony or Zend frameworks, there are other frameworks that has similar feature. If you need this quick, you can get it installed and test out what you're looking to accomplish.
Also take a look at Symphony snippet on Request & Response - Listening service
http://php-and-symfony.matthiasnoback.nl/2011/10/symfony2-how-to-create-a-custom-response-using-an-event-listener/
Something on previous post from Stackoverflow
symfony provides a solid framework for HTTP and restful API through which jQuery mobile can be configured and then if you extend TWIG for a template, then Symfony acts as the bundler and composer through with routing can take place. While Symfony does not run native apps, they need to retrieve and store data and on that front a framework such as Symfony works well. So one could argue that one could use APIs for multiple clients (iOS, Android and more) and then reuse controllers and use formats to generate XML/JSON thus theoretically it should work with Phonegap too.
#ref: Creating mobile app in Symfony2