I am working on a frontend project and need to develop a frontend for an already existing backend developed in PHP. I need to extract all the endpoints from the server code and build the frontend accordingly. I need to know where exactly the endpoints are created or listed in PHP code so that I can understand their payload and header requirements.
I have a nextjs app that I'm using to process stripe payments that I've deployed to Vercel. The app is simply a form with tons of functionality built in but requires the use of an api (which is why I'm using nextjs). What is the best way to get this into a php site? I need to access the nextjs api in order to communicate with stripe. Otherwise I would have just built the react app in the php site and rendered it on the page in question per usual. I've never done this before, so please any recommendations would be huge.
Here are the options I've come up with:
iframe. I've never been a huge fan of these, but figured this was an option. I can render my app via iframe on the php site.
use the vercel deployed nextjs app strictly for the api and build the react form into the php site. Then I would simply change the api requests to point to the vercel deployed nextjs app instead of a local api.
Are there better more efficient methods?
Try vercel-php, a PHP runtime for Vercel. Using the configuration described in the README, you can use a PHP repository as your backend and fetch data from there for your NextJS app.
Alternatively, you can use this directly in your NextJS repository and instead of having the api folder inside the pages directory, just have it as a top-level directory
I'm planning on creating a multi-page web app using Laravel as a back-end REST API and a Vue.js front-end to consume this API.
To be clear up front, I'm not interested in code snippets of exactly how to set this up, unless some will help visualize the architecture.
What I would like to know is how this 'Split-Stack' can be deployed in a completely separated manner. I.E. neither stack shares a codebase, and are stored in completely independent repositories.
I'm not very familiar with JavaScript frameworks beyond jQuery, so I think my lack of understanding lies mainly in the Vue.js department. Some questions which stand out in particular are:
Can a Vue.js application be hosted by a web server to serve static HTML files, if so, which one is compatible?
Can both the front and back end services run on the same server, on different ports for example, and what would be any best practices for this?
And how is login authentication affected by running a web app in this way, and should I be looking into creating some kind of OAuth authentication between the front and back ends?
After reading many blog posts, it is obvious that this architecture is possible, but I'm struggling to find details on how exactly this is configured to be completely separate.
The tools and technologies don't necessarily matter here, but any specifics for Vue.js and Laravel are appreciated.
I have a VueJS Front-End set up with an ExpressJS Back-End, which is very similar to what you are talking about. And yes, it is entirely possible. So let's take a look at each of your questions individually.
Can a Vue.js application be hosted by a web server to serve static HTML files, if so, which one is compatible?
Yes, when you run VueJS, you can either build it as a static application or serve it as a NodeJS Application.
See the Deployment section of the Vue CLI 3 documentation here. It explains how the /dist directory is used to serve the VueJS Application in the manner you are intending to.
Can both the front and back end services run on the same server, on different ports for example, and what would be any best practices for this?
I recently posted an example of how to host both your Front-End and API on the same server here. (Includes Coding Examples and Explanation). This answer references ExpressJS as the API, but the principles are the same. Really, just have your Front-End listening on port 80 and have your API operating on a different, unused port (ie: 8081).
And how is login authentication affected by running a web app in this way, and should I be looking into creating some kind of OAuth authentication between the front and back ends?
I handle all authentication on the back end. Basically, in the Vue Router, you can set a secure parameter. Then declare a router.beforeEach((to,from,next) => {}); call towards the end. This call should then check to see if the user has a valid login token and redirect them to the applications login page after setting a cookie with the URL the user was asked to login from so that they can be sent back to it after logging in.
In our case, we have the user redirected to the VueJS Route /saml/login. The /saml/login component. This component makes a call to the API and returns the address the user should be redirected to to login. In our case, it is the API (which is running on the same server, but a different port [see answer above]), www.example.com:8081/api/v1/saml_login. This then works with the IDP and receives the token and user data. This is also where you would perform you ACS functions (provisioning the user, updating the login time or user data, etc.) After receiving the token, it is placed into a cookie or other placeholder so that it can be used to validate against the token stored in the Database when the user was validated initially. (It is a best practice to set expiration's on your tokens). The user is then redirected to the url stored in the cookie that lets us know where they were asked to sign in from so they can view their content without having to look for it again. (Happy to share code on this if you want)
I think using Firebase or Auth0 Authentication is one of the best ways to do this. Firebase or Auth0 will take care of all the authentication for you and allow your backend to verify the authenticity of your front end. So that makes it much easer to separate the two.
There is an admin SDK for connecting Laravel to Firebase and there are templates and existing authentication SDK's for Vue. There are a few articles which sort of describe it but I haven't seen anything that pieces it all together yet. I was able to figure it out from 2 or 3 different articles and it ended up being easier than I thought it would be.
I have PHP application in Symfony 2.8 and its all REST API in ec2
Frontend is hosted in separate EC2. I am using ELB.
Now I want that only my reactjs front should be able to call API endpoint and if other try via curl or postman then it should not work.
Also I want to have some part like /public to open to public so that anyone can access that.
I am not sure if its possible to do at Symfony level or secuirty groups or NACL or ALB level.
Any ideas?
First of all you can just implement authentication and you reactjs app will only that can access this with the right credentials.
Or you can maybe verify the user-agent. You can create a specific user-agent for your react js app and check it in your endpoint.
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.