Reactjs is quite new to me but I am able to create my components and load them in the view etc.
I am creating a form with react which I want to get data to bind from my api or sending data to my api.
Of course, I want some user validation on my input fields but I have red that validation usually isn't done by reactjs itself. Now my question is; should I interact with a library as jQuery for validation or with the api response given the input arrows and place them in the view if they occurred?
Thanks!
You should always validate on server - even if you validate on client. That's rule we have to obey, amen.
Should you validate on client (React?). No, maybe, probably. Personal choice here.
I don't. I send data to server as is, validate there, process validation errors (if any) on client afterwards.
Why I don't?
- I don't like inline validation even before I submit form
- I don't like double work for one very same task (managing rules, syncing them across client and backend, ...), not to mention you have to handle error responses from server anyway.
Should you interact with jQuery?
Despite it's possible, don't. Do it in React land, will save you from issues with keeping UI in sync, ...
If you're using Redux, redux-form will offer you a great solution for form validation. It's a very simple and easy to use library.
Related
Theres a ton of videos and websites trying to explain backend vs frontend, but unfortunately none of them explains it in a way that you know how to develop a backend - driven website (at least I haven't found anything good).
So, I wanted to ensure that I understood it and kindly ask you to confirm or correct me on this topic.
Example:
I wanted to build Mini - Google. I have a Database containing 1000 stored websites.
Assumption #1:
Everytime I type something into the search bar, the autofill suggestions change. This means, everytime i type, another website / API gets called returning the current autofill suggestions. On a developer site, this means the website e.g. is a Python script which gets called with the current word typed in as a Parameter and is returning all suggestions as e.g. JSON:
// Client Side Script
function ontype(input):
suggestions = get("https://api.googlemini.com/suggestions?q=" + str(input))
show(suggestions)
Assumption #2:
This also means I could manually call the website containing the Python script, providing a random word and it would always return a JSON containing the autofill suggestions for that word.
Question #1:
If A#1 turns out true but A#2 turns out false, how could I prevent a user from randomly accessing the "API" while still returning results when called by a script?
Assumption #3:
After pressing enter, my website googlemini.com/search?... would be called. As google.com/search reloads everytime searching for a new query (or going to page 2 etc.), I assume, instead of calling an API, when the server gets the client request, it first searches through its database, sorts the results and then returns a whole html as a static webpage:
// Server Side Script
#app.route("/search")
function oncall():
query = getparam("q")
results = searchdatabase(query)
html = buildhtml(results)
return html
Question #2:
Often, I hear (or at least understand it this way) that database and webserver are 2 seperate servers. How would that work? Wouldn't that mean the database server needs to be accessible to the web too (of course it would have security layers etc., but technically it would)? How could I access the database server from the webserver?
Question #3:
Are there, on a technical basis, any other ways to build backend services?
That's it. I would also appreciate any recommendations like videos, websites or others to learn how to technically setup and / or secure backend servers.
Thanks in advance.
For your first question you can yes there is a way to prevent miss use.
What you can do is add identifier to api like Auth token to identify a user and every time a user access the api you can save the count on the server n whenever the count has exceeded a limit within a time span you can reject the call. And the limit can be set in such a way that it doesn't trouble the honest user and punishes the wrong one. There are even more complex and effective methods but this is the basic idea.
For question number to let me explain you a simple concept a database is a very efficient, resourcefull and expensive data storage solution we never want it to be used in a general sense as varible store or something. We always want to access the database in call get the data process the data update the data. So we do it data way and its not necessary you make sepreate server for data base. The thing is we mostly make databse to be accessible to various platforms android, ios, windows. So its better to add some abstraction and keep data base as a separte entity.
For the last, I am not well aware about what you meant by other but I am listing some backend teechnologies, some of these might be used in isolation some of these not some other tools as well.
Django
FLask
Djnago rest
GraphQL
SQL
PHP
Node
Deno
I'm building a REST API and I'm trying to keep it as RESTful as possible, but some things are still not quite clear for me. I saw a lot of topic about similar question but all too centered about the "simple" problem of updating data, my issue is more about the business logic around that.
My main issue is with business logic triggered by partial update of a model. I see a lot of different opinion online about PATCH methods, creating new sub-ressources or adding action, but it often seems counter productive with the REST approach of keeping URI simple and structured.
I have some record that need to be proceeded ( refused, validated, partially validated ..etc ), each change trigger additional actions.
If it's refused, an email with the reason should be sent
if it's partially validated, the link to fulfill the missing data is sent
if it's validated some other ressources must be created.
There is a few other change that can be made to the status but this is enough for the example.
What would be a RESTful way to do that ?
My first idea would be to create actions :
POST /record/:id/refuse
POST /record/:id/validate ..etc
It seems RESTful to me but too complicated, and moreover, this approach means having multiple route performing essentially the same thing : Update one field in the record object
I also see the possibility of a PATCH method like :
PATCH /record/:id in which I check if the field to update is status, and the new value to know which action to perform.
But I feel it can start to be too complex when I will have the need to perform similar action for other property of the record.
My last option, and I think maybe the best but I'm not sure if it's RESTful, would be to use a sub-ressource status and to use PUT to update it :
PUT /record/:id/status, with a switch on the new value.
No matter what the previous value was, switching to accepted will always trigger the creation, switching to refused will always trigger the email ...etc
Are those way of achieving that RESTful and which one make more sense ? Is there other alternative I didn't think about ?
Thanks
What would be a RESTful way to do that ?
In HTTP, your "uniform interface" is that of a document store. Your Rest API is a facade, that takes messages with remote authoring semantics (PUT/POST/PATCH), and your implementation produces useful work as a side effect of its handling of those messages.
See Jim Webber 2011.
I have some record that need to be proceeded ( refused, validated, partially validated ..etc ), each change trigger additional actions.
So think about how we might do this on the web. We GET some resource, and what is returned is an html representation of the information of the record and a bunch of forms that describe actions we can do. So there's a refused form, and a validated form, and so on. The user chooses the correct form to use in the browser, fills in any supplementary information, and submits the form. The browser, using the HTML form processing rules, converts the form information into an HTTP request.
For unsafe operations, the form is configured to use POST, and the browsers therefore know that the form data should be part of the message-body of the request.
The target-uri of the request is just whatever was used as the form action -- which is to say, the representation of the form includes in it the information that describes where the form should be submitted.
As far as the browser and the user are concerned, the target-uri can be anything. So you could have separate resources to handle validate messages and refused messages and so on.
Caching is an important idea, both in REST and in HTTP; HTTP has specific rules baked into it for cache invalidation. Therefore, it is often the case that you will want to use a target-uri that identifies the document you want the client to reload if the command is successful.
So it might go something like this: we GET /record/123, and that gives us a bunch of information, and also some forms describing how we can change the record. So fill one out, submit it successfully, and now we expect the forms to be gone - or a new set of forms to be available. Therefore, it's the record document itself that we would expect to be reloading, and the target-uri of the forms should be /record/123.
(So the API implementation would be responsible for looking at the HTTP request, and figuring out the meaning of the message. They might all go to a single /record/:id POST handler, and that code looks through the message-body to figure out which internal function should do the work).
PUT/PATCH are the same sort of idea, except that instead of submitting forms, we send edited representations of the resource itself. We GET /record/123, change the status (for example, to Rejected), and then send a copy of our new representation of the record to the server for processing. It would therefore be the responsibility of the server to examine the differences between its representation of the resource and the new provided copy, and calculate from them any necessary side effects.
My last option, and I think maybe the best but I'm not sure if it's RESTful, would be to use a sub-resource status and to use PUT to update it
It's fine -- think of any web page you have ever seen where the source has a link to an image, or a link to java script. The result is two resources instead of one, with separate cache entries for each -- which is great, when you want fine grained control over the caching of the resources.
But there's a trade - you also need to fetch more resources. (Server-push mitigates some of this problem).
Making things easier on the server may make things harder on the client - you're really trying to find the design with the best balance.
I have the ecommerce store.
I faced automatization problems as my business growing.
My website is written in PHP on Kohana Framework.
I want to automize many processes, but do not know where to dig deeper.
Example:
When order is recieved I want to fire the event "order.recieved". This event knows that my system needs to fire subevents and other actions:
to log inventrory changes asynchronously;
send to the procurement module out-of-stock products and their quantity;
to recreate sliced inventory table asynchronously;
send real-time message to crm system that order is recieved;
send sms to the client with message "We will call you soon";
etc.
Solutions I have in my head:
1) I think the simplest way is to rewrite my application on Laravel framework with it's event dispatcher.
Challenges:
I want use fifo (First In, First Out) for the inventory change;
I need digging to the code to know how many events I have in my system, when they are used,
2) Use AMQP Middleware like RabbitMQ.
Challenges:
I need digging to the code to know where exactly message is sent;
Maybe It can be solved with some event dispatcher, but ->;
Again, I need digging to the code to know how many events I have in my system, when they are used
Are php workers/consumers good to handle messages? Or I need to use python, nodejs?
Challenges:
I need to have many php workers/consumers. I think PHP is not good to handle this.
3) Use some webhooks management system.
4) Study more and use some bpm engine. Only one thing I know right now I can benefit using business rule engine for complex discounts.
What solution I need to take and get deeper with it?
In iPhone I have a register form composed of many UITextField. Now I have no validation on any of them and leave this to server to send me back errors messages.
The problem is how should I formatted error message from server. It used to be
{
email: ["email must be valid", "list of error message for this field"],
another_field: ["list of error message for this field"],
...
}
which is perfectly fine for showing error messages in html form, but not quite useful for iPhone.
My question is how should I formatted this errors message to be use for iPhone or should I replicate validation logic into my app for flexible customizable.
Server side or client side validation logic is up to you depending on your situation and there are pro's and cons of each. In general I would recommend client side validation for a few reasons:
API calls introduce problems of their own. What if it fails?
There is latency involved with the call. I don't want a user to type something or push a button and 2 seconds later something pops up to tell me my age is too young or something like that.
API calls use data that folks are paying for. Yes it's not a lot of data but every bit counts.
In general most of the validation logic I end up doing is fairly simple. Things more complicated like email can be tackled with regex.
That's just a few off the top of my head. Of course some things can't be done on the client such as checking for an available username. In this case you'll have to decide how much data from your error message you want to display to your user. In this case it looks like you have JSON and given that JSON can be recursive (dictionaries inside dictionaries or arrays inside arrays) you can write a recursive function to format it (if you want all of it of course). The other option is to have deterministic values in the JSON that you can query for and display to the user.
We have a working web application, which has been developed with ExtJS for client side, and Struts, Spring, Hibernate for server side. now, we are considering to migrate to GXT (or may be GWT itself). The thing is I'm very new to GWT/GXT. and we are trying to decide whether we go down this road or not.
1) Until now, we have 2 domains for our web-app. one is that the application (Struts+...) have been deployed to, and the other is mainly a cookie-less custom CDN. The transfer between client and server is mostly XHR requests, sending/receiving JSON and/or JSONP. But with the new approach ahead of us, I began to understand that we are supposed to have only ONE domain, for the whole GXT application. Is it correct or I forgot to consider something here?
and if not, Is it possible that we deployed just part of the application (i.e. com.ourcompany.webapp.gxt.server.*) to the main server, and the contents that have been compiled and generated by the GWT compiler to the other CDN-like domain?
2) The other big issue we are facing is that the current application is consists of mostly 3 huge modules. One is responsible for "SignIn", the other is for "Webtop", and the third one is "Modules which each users has access to". The latter has been generated on the server due to "access rights" of each users, and obviously could be different from one user to the other.
The only thing I could find on this matter, which might be related is Code Splitting. Although I'm not totally sure if this would be the right solution for this.
We want that the application, on Start Up, checks whether user has been logged in or not. if not, loads the SignIn sets of javascript files (i.e webapp.signin.nocache.js), then after user has entered the correct username/password, unloads this signin file and loads webtop.nocache.js AND modules.nocache.js.
I would be really appreciated if you could help me out.
1) If your GWT app is loaded from a different domain than you have to face the same origin policy. You can not do a xhr to a different domain. You could use the ScriptTagProxy to get around this. But it does not feel very netural.
2) You can use CodeSplitting in order to automatically load a particular part of your application dynamically. All you have to do is to warp your splitt point into an async call.
A detailed compile report gives you a pretty good overview how well code splitting is working.
But CodeSplitting does not unload already loaded code. If its really importend to do so you have to redirect the user to another url in order to load the appropriate user depended module.
Once Javascript code has been loaded and executed its impossible to remove the code from the browsers memory.
Grettings,
Peter