I am a newbie in microservices and done my research on the best practices and how to upgrade from monolithic. I need now concrete steps to move forward.
I am looking to upgrade a monolithic Laravel project to Microservices.
I have started to break the app into smaller apps. So developed multiple Laravel projects each representing a service. To simplify the question:
Authentication app: used for user authentication and registration
ToDo app: used to create a todo-list with tasks for a specific user
So now I have these two apps where each has its own CRUD operations (multiple APIs).
The question is how to move these apps to AWS serverless using Lambda Functions, API Gateways and Connect to PostgreSQL (Aurora DB).
First I need either to use the SAM template or the Bref template? And how to handle that AWS Lamda does not support Laravel?
Each app has several functions in it (the first app has signup, login, reset password...) so does each one of these must be an independent Lambda function? If yes does this mean each has to be a new Laravel project and then I will have to mention the same resource to be used by SAM or Bref to have the different functions to use the same DB.
Lambda creates by default an API Gateway? If yes then shall I create a main API gateway accessible by the user-side which can call the other API gateways? (Main API Gateways filters the request and if related to authentication it redirects to Authentication Gateway that can interact with the different Authentication Lambda functions?
I Will later have definitely to add step functions with SNS queuing support but for now, I need to understand how to move the apps.
And finally, how would you recommend integrating CI/CD into the project?
Thanks for the help!
You can follow the instructions on the Bref documentation, installing both packages.
composer require bref/bref bref/laravel-bridge --update-with-dependencies
To answer your second question, it is your own choice if you want to break it down to smaller individual lambda function, or use the entire app as a function. Both can work. You may also include multiple functions per application and use an API Gateway to route specific request to the respective lambda. If you decide do just have one function, then all requests just have to be routed to the same lambda. It's your choice.
Lambda doesn't create the API gateway by default, the serverless framework does it for you if you include the following lines in your serverless.yaml file.
events:
- httpApi: '*'
I would suggest you stick with one API gateway for a simpler routing configurations. You can configure the API Gateway to route different requests to different services.
Finally you can implement CI/CD with a pipeline, using a Git repo as a trigger and configure CodeBuild to deploy your app to Lambda.
Related
I am new to microservices, I only know the theory, developed some local examples, and also deploy them to AWS, but just that, and I have a project that has to be done with microservices, but my question is about the structure.
For example, I am planning to do the following:
Vuejs SPA for the frontend store in AWS S3- this will make the request to the Main Laravel app
the Main Laravel app to manage the authorization(login, register, password recovery)
When the user is logged in, is redirected to the "posts" page and that page loads all the posts, you can create new posts, delete them, add comments, etc. This would be another Laravel app, another microservice
Then I have another Laravel app for the user profile, where the users can update their information and also monetize their posts with given options
So, this is my plan:
a SPA stored in S3
a microservice for the Main app that handles authorization, this will be stored in lambda
a microservice for posts, this will be stored in lambda
a microservice for monetization, this will be stored in lambda
I am planning to use serverless so I am a little bit confused.
Where should be the AWS API gateway in the SPA or Main app? or how can I configure it
Should I use only one database and each microservice connect to it?
Should I use different databases? if so, can I how can I synchronize them
If a user logs in to the Main app, it generates a token with sanctum or passport, then this token is sent in the header request to the posts or monetization microservice, is ok this approach?
Should I install a Sanctum or passport?
Should I install Sanctum or passport in all the microservices or only in the Main app?
What can I do? thank you.
If I understand correctly you have one UI communicating with multiple microservices in the backend.
Since you are using serverless, a microservice is probably a set of functions around one functionality that are deployed together. That is totally fine.
In general you will want to have a separate storage area for each microservice. If they are physically different databases or not does not make the big difference in cloud environments because you can always change it according to your needs. The important point is that the storage area is encapsulated by the services. This might mean each microservice has an area within a database that noone else has access to.
This also means you have to use interfaces to get data of other microserivces. There are basically two ways to do so:
synchronously API use of other microservice to retrieve data.
asynchronous data replication via a message bus (event-driven architecture).
For token-based auth: your Main app will create an encrypted JWT token using a private key including user information like email, etc. This token has to be stored in the client and sent to other microservices via a header with every request. They can use decryption mechanisms to ensure the validity of the token and need the public key of the Main app for this. You might consider enter link description hereAWS Cognito libraries because they to that job for you
In general, you should overthink using microservice since they are no silver bullet. You should ask yourself the following two questions:
Do I need to scale development? (e.g. 50 developers +)
Do I need independent deployment/service evolution?
If the answer is "no" to these questions you might consider using some best practices of microservices, but I'd advice against introducing the full overhead of microservices. You could also just have some serverless functions working on a common database.
Recently assigned to a new project where we need to build a api centric web application. Requirement is to build 2 separate projects in Laravel one the has all API's that can be accessed by either web or mobile applications(for future purpose) and other is a web application that uses the API's to work almost all of its function.
Building an API project in Laravel is a easy and lots of tutorials are available about using passport etc. But how do i implement that API to web application.
My major question is how do i setup authentication for web application using api, because its default authentication is model based, or my approach is wrong?
Please suggest ideas, because we are currently in planning phase.
Thanks in advance
Each Laravel Project will be identified as it's own "site" so the only suggestion I would have is if you plan to invoke your APIs via AJAX calls to be wary of Cross-Domain Scripting issues.
I want to use laravel(as backend) and angular(as frontend).
As far as I know I can use 2 methods :-
1) I can integrate both frameworks by using API service or
2) I can use monolithic architecture style (using angular with blade template)
As per my requirements 2nd option is better because in it I can use laravel's default functionalities in angular like (Auth, user roles and permissions etc).
But I afraid that 2nd option makes the project complex and messy in future.
which is the better option?
I have used myself Laravel with Angular v2+, the way I did was to make two separate projects, one which creates the API's (The Laravel app) and one which consumes the API's (Angular v6 app). That is how it is meant to work and that is how you should approach it.
If you want to integrate the front with the back end, and still have a powerful SPA, then you can go with VueJS, there are vast resources when it comes to the Laravel Vue combination.
another thing to consider is what is this project about?
is it a client website? or just a web app? does it require SEO? beware.
make sure you fully understand (angular) universal and it's current limitations/problems.
UPDATE: I am currently using Angular 6 with with Server side rendering(universal) and a Laravel API as a Backend solution for a complex & highly ranked website in the UK.
You have API routes available which doesn't look for CSRF tokens. Use any JWT package for web token authentication implementation. Host your Angular app separately and send request to API routes.
Your Angular apps are standalone applications. They don't need Laravel for running on server. You just need to use API routes for working with data.
I am building an application and currently focusing on the mobile part .
I wanted to use Lumen microframework for the server-side and Apis to connect to the mobile app.
However i also wanted to extend the application later on to build a website (Laravel)
They will both be using the same database .
I am wondering whether i should use Laravel directly and make it responsible for the apis too (albeit it would be slower for mobile apps)
Or i was wondering if i can use a combination of both.
Lumen - to deal with server requests e.g : api.site.com/...
Laravel - to deal with the website e.g : site.com/....
You could do either or, but I would suggest keeping the website and the API isolated.
I actually just finished up a similar project.
I have a mobile app built on Ionic, an API built on Lumen and an admin CMS built on Laravel. The CMS updates content in the API via authenticated API calls and then the app pulls from it.
If you take this route, you could make API calls from the CMS/Website using client side or server side requests. My CMS uses server side calls leveraging Guzzle.
I would suggest looking at sharing models between the two applications such that you don't have to update content via API calls. Here is a nice article on how to do so.
I think this question relates to most PHP API's you download and run in your application. I want to integrate the Klarna API with my CakePHP application. Now, I am not a very seasoned CakePHP programmer so my questions might be very rudimentary. But I haven't figured this out conceptually, how it works with external non-CakePHP software in a CakePHP app. Basically how do I set it up and use it.
In which folder do I put the Klarna files in my CakePHP app? Webroot?
To initialise and configure the Klarna API for use, do I simply put the Klarna code in the controller without messing about with any of the CakePHP component / plugin load procedures?
Do I then run the API code in the controller as well?
I don't need to be using cURL to talk to Klarna in this case right? The Klarna API will make the call to Klarna's servers itself?
Provided you have received testing login credentials from Klarna, this is a working example:
Download the PHP API from Klarna. The files should be placed in the "/Vendors" folder as per
Loading Vendor Files in CakePHP 2.0
& App Class, I put them in a folder named "klarna" for the sake
of organising things. Klarna API consists of quite a few files so
can be a good idea.
You'll initialise and setup the API in the relevant
controller, or I did at least. To load the vendor files do:
App::import('Vendors, 'klarna/klarna');. Given CakePHP's folder structure, I had to modify a couple of lines from the .getAddresses file example. One was previously '/transport/xmlrpc-3.0.0.beta/lib/xmlrpc.inc', became '/vendors/klarna/transport/xmlrpc-3.0.0.beta/lib/xmlrpc.inc'. Similar for the one two lines below. Remember to set the test-accounts "Shared secret" and "merchant ID" as well as having the right test-server configured. Then you can test the API against one of Klarna's test persons.
Yes, the configuration and execution of the Klarna API both happens
in the controller as per examples. It's just normal PHP code though.
We don't need to be using cURL for this API. The API takes care of the calls itself.