I am trying to make backend applications to improve myself with python web frameworks. I need to perform certain validation processes for the data in the requests. Does it make more sense to do the validation in the serializer or model?
Related
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.
I am new to Ember and am used to the MVC model of creating controllers to move data between the view and the server. With Ember, it appears that controllers are support but there is very little documentation on them on the Ember website. From what I can tell, there is an alternative method to save data through the route. Is there an accepted paradigm for how to save data from the front-end to the back-end in Ember?
The Ember guides show you how to use different alternatives.
One easy way is to use Ember data to handle the rest interface with the backend.
Regarding architecture design, you can use the routes or the controllers to interact with you backend using the store.
In our projects we retrieve data in the route, and store it from the controllers.
I have created a backend code in spring-boot for an android app.
My question, is there any rule for distinguishing between the validations at backend side or at frontend side?
For example- for user creation blank fields should be only checked at the frontend side but for testing backend services alone is it okay to have validations on the backend side.
If we just do validations at the frontend side then the problem arises when we test backend services alone.
As general rule, data sent from the client cannot be trusted. E.g. even if the client validated a field is not null, you should assume that field was not validated at all.
You should implement similar validation logic on the backend as well.
Here's the starting point for implementing validation with Spring, based on JSR-303.
It's not only "ok" to have validation on the backend but it's required. As #hovanessyan mentioned, you can never trust the data from the client. Never.
As a rule of thumb, APIs need to be bullet proof. All the edge cases (null-safety, type-safety, min/max, custom validations) should be covered and tested. There's nothing worse than an API responding with a 500.
Lots of devs noticed that there's a bit of validation logic duplication between frontend and backend and this is one of the reasons technologies like Node.js became so popular - you could in theory share the validations.
Also, don't be discouraged by having to duplicate your validation logic. It's tedious but necessary.
I'm trying to learn web development.
I understand (mostly) the concept of MVC, but I'm confused about why an MVC model is used on the server side...like Spring MVC. Isn't the server side the Model and Services, and then the client side Services, View, and Controller (AngularJS even makes that pattern explicit on the client side)?
I'm really struggling with how the MVC model fits into or facilitates server-side development.
MVC is a pattern used by much more than just web applications. Any app with a UI could use an MVC pattern.
The idea is that you have a View (html, or a window in your OS, or even a report or something), and you have a model that represents the dynamic parts of that view. Then you have a controller that is dedicated to processing input and doing the "business logic" to generate the model and apply it to the view.
So.. for example on the Server you might have this MVC pattern:
A controller receives the HTTP request and processes it.
It builds a model
The model is applied to a view to generate HTML and send it back as a response.
On the client it will be similar (but a bit different in Angular's case):
A controller is used to determine and manipulate the model.
The model is then bound to your view via directives. (Angular is really more of an MVVM pattern, but it's similar enough)
The view is similarly bound to your model via directives. (this is where the MVVM part comes in).
The idea here is that both the model and the view are kept up to date by directives.
The controller just contains "business logic" for manipulating the model.
Clear as mud?
No worries. Just know this: It's just a common pattern. It's not "server specific" or "client specific". It can be used anywhere by anything requiring data to be scrubbed into templated output.
EDIT: More thoughts.
In the case of a Web API that serves up JSON (or even XML) on the server, you're still using MVC in most cases. This is because what you're doing is:
Process the request in a controller.
Build up the model in the controller.
Render the model to a "view", which in this case is a view that serializes it out as JSON.
In the good ol' days of yore, the client side was only a display. The server was responsible for communicating with the model, applying business logic, generating a view, and sending the static, rendered content back to the client (browser).
As the web matured, some of those responsibilities migrated from the server to the client. Now, the server-side is often a thin layer like RESTful API that stores the "official" business logic (rather than convenience logic on the client) and stores the model. But for performance and user experience, the client now stores a copy of the model in its own model layer, communicating with the server and/or local storage as necessary, and having its own controllers and view logic to provide an awesome user experience.
So does MVC still apply on the server? Yes! It's just different. The server often generates the initial view from which the client-side application runs (taking localization or internationalization into account, for instance) and still houses the official model. But more importantly, the "view" in MVC just changed. Instead of the server-side view being HTML, it's now JSON or XML that the client application consumes instead of just renders.
So for functionality's sake, we still use MVC on the server. But for an awesome user experience, we use MVC on the client-side now too.
We are in the process of designing/creating restful web services that will be consumed client side using XHR calls from various web pages. These web pages will contain components that will be populated by the data retrieved from the web services.
My question is, is it best to design the return data of the web services to match specifically what the client side components will require for each page? Therefore, only one XHR call will be required to retrieve all the data necessary to populate a specific AJAX component or to update a specific page. Or is it more advisable to develop generic web services, that match for instance a database schema, and will require multiple XHR calls client side to retrieve all the data to populate an AJAX component? The second approach seems to lead to some messy coding to chain calls together to retrieved all the data required before updating an AJAX component.
Hopefully this makes sense.
You should always design services based on what they are to provide. Unless you need a service that retrieves rows from the database, don't create one. You may find you need a service that returns complete business entities - they may be in multiple tables.
Or, you may just need a service to provide data for UI controls. In that case, that's what you should do. You may later find that two operations are returning almost the same data, so you may refactor that into one operation that returns the data for both.
My general rule of thumb is to do what ever is the smallest to transmit over the ajax call. In theory, the more data that is sent to the client the slower the update process. This, of course, would necessarily mean specific services for specific pages.