4 ms·

I think this can make it easier for hackers to understand your data model right from the beginning. Even with Firebase I don't manipulate data in the client bec

by ramon 8y ago

I think this can make it easier for hackers to understand your data model right from the beginning. Even with Firebase I don't manipulate data in the client because anyone can just open a f12 and start changing the data as they wish, it's a good idea but it's a hacking world and we need to make sure that data manipulation stays in the backend only with CORS, SSL and requests protection against injections either in SQL or anything else can even be a header. I understand were you're coming from, I used to think why not. Well the security is still the barrier and even back in the old ages of Java EE the beans stayed safe guarded in the backend from the Web Project.

ShishKabab 8y ago
If that's your concern, part of the plan for later would be to make it easier to generate a REST/GraphQL API that you can easily consume on the client side, while not having any schema data in the front-end. Say you'd have a TodoStorage which has high level methods like markAsDone(), you could have that either write directly to IndexedDB in your dev workflow, or move that class to the backend, and replace the front-end version of TodoStorage talk to a GraphQL API instead. The point is to have a choice, and allow the user of the library to understand the risks of technologies involved and use and mix them according to their needs with minimal efforts.