I'm trying to do a Symfony2 centric application and re-use all the Bundles for the web front app. The application will be divided in three API, FrontEnd, BackEnd, so that we can code the API like a Service Bundle and use it across the hole application and also will provide an API for our application. The FrontEnd will use the API as a Service and it will have all the front for user use. And the BackEnd will also use the API but providing a different url to admin the app.
This is the structure I'm using:
/app_api
/app_frontend
/app_backend
/bin
/src
/vendor
/web_api
/web_frontend
/web_backend
This will be traduced to:
api.domain.com (app_api, web_api)
www.domain.com (app_frontend, web_frontend)
backend.domain.com (app_backend, web_backend)
What do you think?
Is this posible?
What about performance, even if we are using APC?
If you have another solution let me know.
Thanks & Regards to everyone
Related
I have 2 projects Symfony plus react.
They exist in 2 directories and react app uses Symfony app as api backend.
I tried to figure out the best way to connect it and I used Apache Alias
(/front -> my frontend directory because adding /api - backend dorectory broke backend )
Now..
Frontend app uses things like: .
I could add /front to url but i guess this isnlt right and my app shouldn't care what the aliases are.
What would be the best way to fix that?
Is there a way to configure it in apache or should I add some global variable before every url or is just putting front project inside backend project?
So basicly I bought a domain and created subdomain for backend and everything works well.
I've deployed a very basic Express app through Claudia JS. It's working pretty well, but any links or redirects don't keep the API Gateway stage and so don't work.
For example I have the app deployed at http://example.execute-api.eu-west-2.amazonaws.com/production - that's the equivalent of http://localhost:3000 when running locally. If there is a link on that page along the lines of <a href="/test"> that goes to http://localhost:3000/test locally, but through the api gateway it goes to http://example.execute-api.eu-west-2.amazonaws.com/test - losing the /production part of the URL and therefore not working.
Is there a way to get Express to know that all routes need to be prefaced with /production?
The alternate solution is to use a custom domain, but that seems like a lot of hassle to solve what seems like it should be just a bit of config.
You can use something like this to build the base URL;
https://${req.apiGateway.event.headers.Host}/${req.apiGateway.event.requestContext.stage}
I have a certain page my Jekyll site that I only want to make available to people from my organization's domain (call it example.com).
Am I correct in my understanding that it's not possible to restrict access to certain pages because — as is the nature of a static site — everything has already been served at once?
I'm aware of the jekyll-auth plugin to authenticate users against GitHub, but my situation would require that authentication through Google sign-in.
Jekyll is just a static site generator, so anything related to authentication will depend on what you have available on the webserver that is hosting the site.
Take a look at the Jekyll Google Auth plugin for example:
https://github.com/apcj/jekyll-google-auth
It's basically a trick... Anytime a request comes in for a page, they run it through Sinatra (using the _site folder as the static file folder, just as public would be normally), and authenticate it using apcj/sinatra-google-auth.
So in this case, you know that your webserver must have Sinatra for this authentication method to work.
One alternative would be to password protect your Jekyll site with HTTP basic auth. Aerobatic provides such a feature for static sites hosted with Bitbucket. And yes, you can protect only certain directories of the site.
https://www.aerobatic.com/blog/password-protect-a-jekyll-site
Disclaimer: I'm one of the founders of Aerobatic
You can use Netlify to add authentication to any static site not just jekyll. Deploy your site for free on netlify and use their identity widget..
We are building a fully RESTful back-end with the Play Framework. We are also building a separate web front-end with a different technology stack that will call the RESTful API.
How do we deploy both apps so they have the same domain name, with some URLs used for the backend API and some for the front-end views?
For example, visiting MyDomain.example means the front-end displays the home page, but sending a GET to MyDomain.example/product/24 means the back-end returns a JSON object with the product information. A further possibility is if a web browser views MyDomain.example/product/24, then the front-end displays an HTML page, and that webpage was built from a back-end call to the same URL.
Finally, do we need two dedicated servers for this? Or can the front-end and back-end be deployed on the same server (e.g. OpenShift, Heroku)
You are gonna to dig yourself... deep :)
Simplest and most clean approach with no any doubt is creating a single application serving data for both, BE and FE, where you differ response (JSON vs HTML) by the URL, pseudo routes:
GET /products/:id controllers.Frontend.productHtml(id)
GET /backend/products/:id controllers.Backend.productJson(id)
Benefits:
single deployment (let's say to Heroku)
name space managed from one app
No need to modify the models in many apps after change in one of them
else if
If you're really determined to create a two separate apps, use some HTTP server as a proxy - for an example nginx - so it will send all requests to domain.tld/* to application working at port 9000 (which will answer with HTML) but requests to domain.tld/backend/* redirect to application working at port 9001 responding with JSON.
else
If you are really gonna to response with JSON or HTML depending on the caller you can try to compare headers to check if request was sent from browser or from AJAX call in each controller , but believe me that will become a nightmare faster than you thing... insert the coin, choose the flavor
I thought of a different solution. I'm going to deploy back-end to a subdomain like
http://api.myapp.example/
and deploy front-end to the main domain:
http://myapp.example/
but I think you'd better use 2 different hosts, one for front-end and one for back-end (I searched the Google and this was the result of my investigations
Other possibility (therefore as separate answer) is using a possibility added in Play 2.1.x a Content negotiation I think it's closest for that what you wanted to get initially :)
Indeed its much easier to create a MEAN STACK APP and use one hosting like Heroku for instance.
Your frontend is what it is, front end for your backend. It will be easy to access backend / restfulAPI's and frontend like this:
http://localhost:3000/api/contacts (to access and consume your API endpoint)
http://localhost:3000/contacts (frontend)
NB: localhost:3000 or http://yourapp.example/api/contacts (api)
http://yourapp.example/contacts (frontend)
It's in the URL
I've been looking at backends and APIs for a while now. It seems that sometimes devs will build a regular backend (in say a language like PHP) that handles all the backend matters and sometimes devs will instead choose to build out their backend through an API and then use their own (and possibly other) sites to pull data from this API.
I was wondering this:
Say I want to build a regular backend using a server-scripting language like PHP, which I will use to not only render my main website, but will also allow me to do other server-side scripting etc. Then say I want to use this data from the current site and make it accessible to another site of mine through API calls. Will it be possible to build an API on top of a regular backend?
If the answer yes, how complex can it get to achieve something like this?
What tools or design strategies (if any) would you have or have used for achieving this?
This is an old question, but since I'm here, I may as well provide an answer for anyone wondering. Joe is asking about server-side web APIs versus regular server-side code.
Yes, you can have a "regular" backend and an API backend exist at the same time. If your backend is in PHP, you can refactor and extend your code to handle API requests.
Like Patrick Evans said, an API is the backend. If your backend PHP code communicates with a database to manipulate or retrieve data, then you can consider this an API transaction. Whenever your backend receives a request, evaluates/actions that request, and returns a response, it is essentially acting like an API.
Let's say you own example.com, with an index.php file in the root directory - so when a user requests example.com in their browser, this index.php file is processed and served to them. Now, you can set up this index.php file to handle both regular page requests (i.e. the php script returns an html template that is rendered by the browser) and API calls. This can be as complex or as simple as you want it to be.
The best way to handle this would be to assign different routes for rendering your main webpages and API calls. You can set up routes in the following way...
example.com/index.php?route=api&data=users can be handled by your 'API code' in index.php to return a JSON response containing a list of all the users in your database, while example.com/index.php?route=home will just return your website's home page.