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
Related
I am learning express and the http methods, but I cannot find any documentation on it. Is /api/value just for the json data, like an address just for that data? Just any extra info on it would be appreciated. Like what exactly does it do and if there is any documentation from express about it. Or is this a global term used in urls throughout frameworks and the internet?
For example:
app.get('/api/jackets'(req, res) => {res.send('logic')})
Why do we need to add the api before jackets and what does it do?
It's not necessary, it's used only for a better understanding
The /api request is not required, but putting a prefix in front of the API requests such as:
/api
or, in some cases including a version number:
/api/v1
Allows you to use the same web server for more than one type of request because the /api prefix uniquely identifies each API request as an API request and it can easily be routed to where you handle API requests. You could have plain web page requests from a browser served by the same web server. While, you don't have to use such a prefix, using it gives you the most flexibility in how you deploy and use your server.
Similarly, putting the version in the prefix such as /api/v1 allows you to evolve your API in the future in a non-backward-compatible way by adding a new version designation without breaking prior API clients (you support both versions at the same time - at least for a transition period).
I'm developing a database backed web-app. I will be providing the same basic services to several branches of the same company.
Right now I have an Apache server with virtual servers and a resource server for reporting.
branch1.mycompany.com
branch2.mycompany.com
resources.mycompany.com
So basically when I call resources from the site I pass the site as a parameter.
branch1.mycompany.com -> resources.mycompany.com?branch=1¶meter=1
branch2.mycompany.com -> resources.mycompany.com?branch=2¶meter=1
Even with two branches there is a problem trying to keep up with updating both sites and now, I'm going to be implementing this scheme for seven sites.
So my question is this: Is there a way I can make a IIS or TomEE web-app with the following features?
I want to still allow each branch to access trough its URL
Even when there are 7 URLs; all of them will be pointing to the same web-app
Depending on the URL, is there a way the site parameter can be inferred or calculated so I can call the right resource or web service?
The user should never realize they are accessing a common web-app. (i.e. should not be redirected to web-app.mycompany.com?site=1.)
Tomcat (so tomee) has now a rewrite valve which is close to httpd mod_rewrite, this can surely solve that smoothly. I assume IIS has it as well but don't know it that much. Trick is to reverse proxy the requests.
Using Angular-CLI as a frontend. 4200 port
Using Express as a backend. 8080 port
Directories look like:
Application
- backend
- ...Express architecture
- frontend
-...Angular2 architecture
So I'm running two projects, two commanders, one for frontent, second one for backend. node app.js for backend (8080), ng serve for frontent (4200).
Let's assume that I have a layer in backend which returns some string.
app.get('/hello', function(req, res) {
res.send("Hello!");
}
How can I make a request from frontend to backend and get that string? I don't want to know how exactly should I use Angular2 because that's not the point. I'm asking, what technology should I use to be able connect these two (frontent and backend) sides on different ports. If I just run them and make a request from frontend, I'll get an error because it can't find /hello url.
Your request to /hello means an absolute path inside the application running the angular application, so the request goes to http://localhost:4200/hello. Your angular application just doesn't know about the express application you want to target.
absolute urls
If you want to access the hello route on the other (express) application, you need to explicitly specify this by referencing http://localhost:8080/hello.
cors
Doing it this way, the correct application is targeted, but you will likely run into CORS issues, because the browser will prevent the javascript code obtained from localhost:4200 to access a server at localhost:8080. This is a security feature of your browser. So if you want to allow the code at 4200 to access the backend at 8080 your backend can whitelist this so called origin. For details see http://enable-cors.org/ and a corresponding express middleware you could use to support cors in your backend (https://www.npmjs.com/package/cors).
Using this approach has two downsides in my opinion. First, you need a way to tell your frontend under which absolute url it can reach the backend. This must be configurable because you need different urls for dev, staging and production. You then also need a way to manage all your whitelisted urls because the frontend in production will have a different url than when running the frontend in development. This can get pretty cumbersome to handle.
proxying your backend
A better approach in my opinion is to handle this in your infrastructure by proxying the backend in your frontend application. With proxying you basically tell your frontend server that all requests to some url should be passed through to another application. In your case this could probably mean, that for example you configure a proxy for the path /api/ to proxy the application on localhost:8080. The server then doesn't try to find a url like /api/hello on your frontend application but forwards your request to localhost:8080/hello. In your angular application you then don't need to care about the url of your backend and you can then always do a request to a url like /api/some-express-route.
For this to work you need to configure your angular dev server to proxy the requests. For details on how to do this, please see the docs at https://angular.io/guide/build#proxying-to-a-backend-server. When going to production, you can do this by configuring your web server, e.g. nginx to proxy the requests.
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.
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