3 ms·

> I've literally always had need for validations, background jobs, translations, authentication, authorization, migrations, orm/data libraries, CLI commands for

> I've literally always had need for validations, background jobs, translations, authentication, authorization, migrations, orm/data libraries, CLI commands for maintenance tasks, Sure, I was simplifying to make a point, of course I use all of those. My main point however was that there are defined, standardized solutions for all of those. It's not like there's that much churn in authentication libraries for example, most people would use Passport or just JWT. > but that's a lot of work to get it right, documented, secured and battle proven. It's really not, because again, solutions are pretty standardized.

0xblinq 4y ago
> there are defined, standardized solutions for all of those Really? I have never seen two Next.js projects, open source or not, which use the same subset of libraries. Most don't even share the same "approach" to communication with the backend. Some use GraphQL, some other just API routes, other's proxy to another backend, other trpc, others firebase like solutions, etc... And none of them would qualify as "simple" to anyone else than the person that built it. Even more, no two single projects share the same structure or code organization. > It's really not, because again, solutions are pretty standardized. Tying together all of those solutions and guarantee you're not creating security holes in doing so, documenting it for others and making it robust and battle proven is complex for almost everyone, maybe not for you if you're top 1%, granted. I'd love to hear about those standard solutions you mention, because as I said above, those standard solutions are different for everyone. And I've seen tons of wasted time and effort in discussing what's the "standard solution" to use. From people discussing if they should do validations with yup or express-validator or joi to discussing if they prefer prisma or knex to entire weeks debating if migrating to GraphQL would be better.... tons of time and company money wasted.

0xblinq 4y ago

> there are defined, standardized solutions for all of those Really? I have never seen two Next.js projects, open source or not, which use the same subset of libraries. Most don't even share the same "approach" to communication with the backend. Some use GraphQL, some other just API routes, other's proxy to another backend, other trpc, others firebase like solutions, etc... And none of them would qualify as "simple" to anyone else than the person that built it. Even more, no two single projects share the same structure or code organization. > It's really not, because again, solutions are pretty standardized. Tying together all of those solutions and guarantee you're not creating security holes in doing so, documenting it for others and making it robust and battle proven is complex for almost everyone, maybe not for you if you're top 1%, granted. I'd love to hear about those standard solutions you mention, because as I said above, those standard solutions are different for everyone. And I've seen tons of wasted time and effort in discussing what's the "standard solution" to use. From people discussing if they should do validations with yup or express-validator or joi to discussing if they prefer prisma or knex to entire weeks debating if migrating to GraphQL would be better.... tons of time and company money wasted.