121–130 of 141 posts
I can't understand how to get a development team starting with something like this to something like a microservices API without a complete/major rewrite or painful decoupling/transition sprint(s). Or am I missing something here?
Are there any isomorphic frameworks or examples that aren't tightly coupled? I can't understand how to get a development team starting with something like this to something like a microservices API without a complete/major rewrite or painful decoupling/transition sprint(s). Or am I missing something here?
This was a really bad time to post this framework, the disillusionment for javascript is at an all time high right now. That being said why Mongodb? NoSql are advantageous for write speeds, which as far as I know isn't particularly important for new applications. I understand that you want "javascript everywhere" but is that really worth the cost of losing the speedy and convenient join statements? I think postgres m…
Earlier quoted context omitted.
You're not "saving down a JavaScript object", as MongoDB does not speak JavaScript. What you're doing is passing an object to your database driver, which then converts it to JSON , and sends it to MongoDB. JSON is an entirely separate language from JavaScript, and it can be used from just about any language. This "convert a native object into the query format" thing is also literally what almost every database driver…
Ok, so I'm saving it down as a JavaScript Object Notation which looks exactly the same as JavaScript. I think that's very convenient and don't see how it's the same as converting for example PHP to MySQL where I'm bound by a schema which looks nothing like my data structure in PHP.
Whether it looks the same is irrelevant. It doesn't even have the same syntax rules. For example, this is valid JavaScript:
{
one: "two",
three: undefined
}
> don't see how it's the same as converting for example PHP to MySQL where I'm bound by a schema which looks nothing like my data structure in PHP
And in 99% of cases, this is a feature, because you can't represent most data as a flat list of nested objects. See also this article: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...
Aside from that, if you want a native nested representation of data in your database, so including relations, you use an ORM. For example, in PHP with MySQL, you might use Eloquent.
How data is represented in your application and how it's represented in the database, are two entirely different things. There's no advantage to be gained from trying to make them the same thing - that's the concern of the database abstraction that you choose to use.
So this is a repo that is being cloned on your computer [1]. I have a couple of questions : 1. Why not just creating yeoman generator? 2. Don't you think it is too opinionated and inflexible to be useful? 1: https://github.com/Hashnode/mern-cli/blob/master/lib/main.js
Earlier quoted context omitted.
Why would an SQL ORM provide validations? The database itself already does. Additionally, user data isn't the only data that needs to be validated. The vast majority of our data is generated by the program itself, and schemaless databases have given us endless headaches with this.
Client-side validation are much more important that server-side validations. Preventing a user from sending bad data to begin with avoids the poor usability of having to send bad a failed request and reset the form for editing. Database constraints only avoid bad data in the database. They still have to be duplicated for error checking in the server and client. Is JS is used on both the server and client, it makes a…
There may be more than one client connecting to the database at the same time (or even internal inconsistencies within the same process), and the only way to prevent data inconsistencies is to hand the final responsibility of validation to the thing that is actually storing the data, ie. the database.
In the end, your database is the single source of truth, as it is the only part of your architecture that is technically capable of doing so. Client-side validation and server-side validation (in the application) are niceties for UX purposes, but do not and cannot replace database constraints.
Earlier quoted context omitted.
You need both. Sometimes the legit input is HTML such as from rich text editors. In those cases if someone types a bold then the form should submit the escaped <script> but also needs to sanitise to make sure that other HTML element types are not present. If you escape one step further you'll lose formatting or the message, so sanitisation is important too, it is reductive to say "always escape never sanitise".
I think your first problem is whitelisting HTML entities. Unless you're composing HTML-formatted email, it's usually better to use a different markup syntax like a minimal markdown or asciidoc that can safely be escaped.
Earlier quoted context omitted.
Ok, so I'm saving it down as a JavaScript Object Notation which looks exactly the same as JavaScript. I think that's very convenient and don't see how it's the same as converting for example PHP to MySQL where I'm bound by a schema which looks nothing like my data structure in PHP.
> JavaScript Object Notation which looks exactly the same as JavaScript. Whether it looks the same is irrelevant. It doesn't even have the same syntax rules. For example, this is valid JavaScript: { one: "two", three: undefined } ... but would be completely invalid in JSON, in more than one way. No, they are not the same. > don't see how it's the same as converting for example PHP to MySQL where I'm bound by a schema…
Earlier quoted context omitted.
Probably because the author was compelled to choose his words wisely to comply with forum policies. In essence "damn idiots" is a toned down version of something far more expressive.
We don't give a shit if you swear. We care about how people treat each other.