I want to develop my own single page web application (SPA) to get to grips with the modern and highly fluid world of web development. At the same time, I would like to use the page rendering technology (SSR) with built in data into html. However, there is an authorization problem.
Suppose that the user has already logged into the account before, as I imagine re-opening the site:
First request: the client makes a request to the frontend server along with identification and authorization data (for example, user id and token; the only option is to save them in cookies), the frontend server makes a request to the api server, transferring these service data, then the api server gives the information about the user and the content of the current page (in the same json), the frontend server renders this into a finished page and delivers it to the client.
Subsequent requests: the client directly addresses the api server, transferring the same (or updated after the first request) authorization data, receives json and processes it independently.
Actually, I want to move on to the question. Do I understand this interaction correctly? Can you do it differently / better? Are there tools that allow, for example, to use the components of the frontend framework as components of the MVC backend framework, so that one server does the rendering without unnecessary requests? Or a unified tool that includes the same coding for the frontend and backend to solve these problems? I will say right away that I would not like to write a backend in JS.
I can roughly imagine how you can get by with one request when using AngularJS (with a module for single page applications) and any backend MVC framework; although there will not be a full-fledged render, but search robots will not have to wait for my first fetch, since the data will be delivered initially, for example, through the data attribute. But in this case, I plan to choose Svelte (Sapper) and Ruby on Rails as the stack, although I think this is not important.
Thank you for your attention to the question!
Are there tools that allow, for example, to use the components of the frontend framework as components of the MVC backend framework, so that one server does the rendering without unnecessary requests?
If that's what you want you can install a frontend framework in Rails using webpacker. After that you will have a folder in your rails project that will contain your Svelte components. Then you import Svelte components in erb templates and pass data as props.
I have tried that approach but personally I prefer a separate frontend and backend talking through API calls. Then in your frontend you need something like Sapper if you need SSR. With webpacker you don't(assuming you mostly use Rails for routing).
If you are worried about authorization it's not really hard to implement. And after login you can store user info on local storage for instance for subsequent requests. But of course if you install with webpacker it's all done within Rails hence it's easier.
From my experience, using webpacker it's easy and quick in the beginning but you are more likely to get headaches in the future. With separate backend and frontend takes a bit more work, especially in the beginning, but it's smoother in the long run.
This helped me set the authentication between rails api and vue frontend.
So, if you wish to separate them, just install Rails as API only and I suggest you to use Jbuilder to build your jsons and serve them to the frontend as you need them.
Related
while building with Laravel probably you may have faced the same situation where you have a RESTful service with JSON replies and, at the same time, you need to have a frontend able to consume those APIs to offer a web interface.
Now, the most obvious solution would be to use Laravel Blade template engine and to diversify routes according to the address (/resource or /api/resource). However, this approach brings in an additional burden, directly reflected in controllers, where are you have to consider not only the reply itself but also whether it comes from a device or from the web interface and reply accordingly.
I have also seen a lot of frontends actually detached from the backend and built using serverless technologies such as Angular or React, so that both the web interface and the mobile app consume the same APIs and the backend can be much simplified.
Let's take as an example a "Uber for..." service consisting of a native app, a PWA and an admin interface (web), which approach would be the most advisable and why?
My single page app is hosted on Google's cloudstore. I love that I don't have to worry about a server. The app is, naturally, javascript heavy.
Now I would like to add a feature where users can store some data, generate a link to be shared with others and retrieve stored data. Think of a pastebin where some snippet of text is saved and a unique link is generated to be shared with others.
In fact, if it helps, think of this as my attempt to create a pastebin without having to setup a server.
It looks like Google's cloud datastore nosql solution is what I want. Given a key, it will return a snippet of text. However, all the examples on the documentation page imply that I have to setup a back end service using python, node, etc.
Questions:
Can't I just read and write from a web page, perhaps using ajax style http call (since I need to get and put text snippets once data has already been loaded)? I believe I can take care of cross-origin issues by changing some configs in the cloudstore static website server.
Obviously I don't want to serve any encryption keys from the web page. I'm hoping that since my site is served from Google as well, I can configure the nosql service handle permissions intelligently for this scenario.
Is there any documentation which shows how to do this correctly?
Google Datastore is not supposed to be used from client side, it's a served side database. You cannot do that w/o having server side code to authenticate, authorize and validate db related requests.
But there're an alternative. Firebase is a ready to use backend for client side applications, including Javascript apps. It's a separate project, that belongs to Google but not (yet?) part of Google Cloud. Take a look - https://www.firebase.com/
Although the API Rest is still beta, it is possible now to connect from a web client or anything RESTful capabilities. https://cloud.google.com/datastore/reference/rest/
So, I'm starting out building a social network web app. I'm looking into how to fit the parts of my stack together and I'm looking for some guidance about what various frameworks will allow me to do. My current stack idea is to have:
Firebase JSON API: serving user, post, comment, and all the other data
EmberFire: to plug that API into EmberJS
EmberJS: my front-end MVC (because I'm new to MVC and Ember seems the most accessible)
What I'm stumbling on at the moment is how I'm going to implement users with this stack. I've looked at basic authentication stuff but I haven't found anything that would allow me to allow certain actions and views for certain users and not others - the basics of a social network really.
Is it sensible to be doing this stuff in front-end MVC? If so what should I be using to do authentication/personalisation? If not, should I just be doing a PHP/SQL setup? I'd rather avoid that because my skills are all front-end.
If you are just getting started, Firebase is a great service to learn on due to their 'back end as a service' model - you will spend more time building/modeling your data and less time running/installing. Not that you won't want to learn more about that later, but it lets you focus on one piece at a time.
From an access perspective, JS/NoSQL vs PHP/MySQL isn't going to be the issue. They each have their own security requirements - it's more that PHP/MySQL has had more time to establish those rules. Additionally, Firebase being a hosted service has it's own set of requirements.
Firebase security rules are a little weird when you first look at them, but they begin to make some sense after you sit with them for a bit. The Firebase docs are actually a pretty great resource. https://www.firebase.com/docs/security/
Basically, if you use a Firebase 'login provider' it makes Firebase act as both a database and a authentication manager, and the combo helps keep users 'fenced' to where you want them. You can use data from other paths, variables, validation rules, etc. You can even make a 'custom login provider' if you need to integrate with an existing one.
Finally, on the client end, your view can respond to whatever Firebase returns - if a user does 'hack' their way through to a page they shouldn't be on client side, no data is returned anyways and no submitted information would be allowed because of the rules.
I want to create a web app that uses Twitter Bootstrap for the front end, and the backend uses Spring+Hibernate.
Now, some data has to be stored in each user's session-- how do I store/manage such data?
Do I have to use a 3rd party JS framework like Angular (by Google) or some other framework for this purpose?
Also, in such a hybrid app, should I use the JS framework (like Jquery or Angular JS) for storing the data and then send it to the Spring + Hibernate API? What I mean is, I can as well store the object-> relational DB mapping in the js framework, and use Spring only for basic database inserts/updates/selects?
Twitter bootstrap is a CSS framework with some javascript plugins, and is not a language in itself. Using it or not using it will have no impact on what you can/can't use on your backend.
As for sessions; sessions should always be stored server-side... therefore using Bootstrap will have no affect on your implementation of sessions.
Finally, in regards to keeping any of your database logic client side in javascript, NEVER do this. Javascript code can extremely easily be modified by the user, so anything client side should be considered unsecure. Do not ever put anything unsecure in your database.
We can use Twitter Bootstrap for the front end, and Spring MVC -> REST API for the back end...
For simple apps, ex search-only apps we can straightaway create an API and use JQuery to connect to the API and fetch data.
For more complex apps, the problem is that REST APIs dont store session data... For this, however we can use Spring MVC-> REST API as that has support specifically to handle sessions.
Refer http://tedyoung.me/2011/10/19/practical-spring-mvc-part-5-sessions/ that explains how to store session data using Spring MVC- and the front end is a simple HTML/CSS web page.
I am trying to make a web app using ExpressJS and Coffeescript that pulls data from Amazon, LastFM, and Bing's web API's.
Users can request data such as the prices for a specific album from a specific band, upcoming concert times and locations for a band, etc... stuff like that.
My question is: should I make these API calls client-side using jQuery and getJSON or should they be server-side? I've done client-side requests; how would I even make an API call from the server side?
I just want to know what the best practice is, and also if someone could point me in the right direction for making server-side API requests, that would be very helpful.
Thanks!
There's are two key considerations for this question:
Do calls incur any data access? Are the results just going to be written to the screen?
How & where do you plan to handle errors? How do you handle throttling?
Item #2 is really important here because web services go down all of the time for a whole host of reasons. Your calls to Bing, Amazon & Last FM will fail probably 1% or 0.1% of the time (based on my experiences here).
To make requests users server-side JS you probably want to take a look at the Request package on NPM.
It's often good to abstract away your storage and dependent services to isolate changes and offer a consolidated and consistent web api for your application. But sometimes, if you have a good hypermedia web api (RESTful responses link to other resources), you could reference a resource link from another service in the response from your service (ex: SO request could reference gravatar image/resource of user). There's no one size fits all - it depends on whether you want to encapsulate the dependency or integrate with it.
It might be beneficial to make the web-api requests from your service exposed via expressjs as your own web-apis.
Making http web-api requests is easy from node. Here's another SO post covering that:
HTTP GET Request in Node.js Express
well, the way you describe it I think you may want to fetch data from amazon, lastfm and so on, process it with node, save it in your database and provide your own api.
you can use node's http.request() to fetch the data and build your own rest api with express.js