what's the proper choice for regular web backends? any answer involving Rust or C/C++ is de facto discarded
>Requirements
Large enough application that it needs to be usable and maintainable at a certain codebase size. Performant enough. Convenient to use enough. Balance is the prime, most important requirement.
 Thalidomide Vintage Ad Shirt $22.14 |
 Ape Out Shirt $21.68 |
Thalidomide Vintage Ad Shirt $22.14 |
It's gigakino but obscure enough to filter pajeets and brainlets
Explain yourself anon.
>Explain yourself anon
Ktor.
It's fast enough, and more importantly, absolutely comfy to write in. Here's how much code you need to add an endpoint where you can delete a customer:
post {
val customer = call.receive<Customer>()
customerStorage.add(customer)
call.respondText("Customer stored correctly", status = HttpStatusCode.Created)
}
>can delete a customer
Add a customer, obviously*
All validation, conversion and serialization etc etc etc is done automatically.
Isn't the case with every backend framework
what do you mean?
>All validation, conversion and serialization etc etc etc is done automatically.
Isnt that what backend frameworks are supposed to do?
Yeah, kind of, but they don't provide the same level of functionnality in doing so. I would like to see something like LINQ implemented properly in other languages. The Java StreamAPI isn't there yet and libraries that try to do the same for Javascript and Python are poor knock-offs of LINQ (like linq for JS). When it comes to validation, not all frameworks offer that features and not all of them do it properly. And all ORMs don't offer a good abstraction against SQL Injections. Active Record (Ruby) and Sequelize (Javascript) are vulnerable to SQL injections;
this doesn't look mockable, therefore, isn't unit testable. Or is everything have an interface that we can use to mock?
>this doesn't look mockable, therefore, isn't unit testable. Or is everything have an interface that we can use to mock?
Watch this
private val apiMockEngine = ApiMockEngine()
private val apiMock = Api(apiMockEngine.get())
@Test
fun `test posts`() = runBlockingTest {
val posts = apiMock.posts()
assertEquals(10, posts.count())
}
>JVM
The proper choice is the boring choice. C# or Java. Or anything else in the .NET or JVM ecosystem.
Which one anon. Which one.
If you don't mind using Windows as a dev machine (you can deploy wherever but most of the dev tools are Microsoft), .NET
I already use a windows dev machine, but why is it better if i have a windows dev machine? Java works well there too.
C#'s just a little better than Java and the .NET VM is just a little better than JVM implementations (much better than standard ones, but a lot of big players have moved into the JVM scene and there are probably some decent ones in there). Not enough to make Java non-viable, but all other things being equal I'd choose C#.
I actually already made my mind on the tech stack i would use and already wrote the first service but i wanted to compare the path i decided to take to the choices of others. The servers will be running on ASP.NET Core v6 with PostgreSQL databases and a YARP server for load balancing.
It wasn't a very hard choice to make. The only real alternatives for that kind of app were Java and Kotlin (maybe Scala too). The hard part is deciding what the desktop application will be built in. I can't use MS solutions because they are Windows only (and the software client must be accessible from Macs too) and i will not use MAUI because
>1- It's not mature enough yet and the project is too sensitive for testing new experimental techs
>2- I have the feeling that MAUI is a mobile-first technology which does not suit my needs at all. I want a proper desktop toolkit.
>inb4 "eeeh use electron brah". Don't. Just, shut up.
This site is not entirely filled with morons after all. The guys who suggested Kotlin, Elixir, Java or Clojure actually make sense. I expected to get a lot of Nodejs or Rust suggestions.
tell me exactly why you didn't consider php with laravel
why would you use something that somehow managed to be slower than python
>php slower than python
what php is the fastest web oriented language php was literally born to be fast
no I meant lavarel
Then you would be right. Laravel manages to be even worse than Django which is a very impressing accomplishment.
Yeah, PHP is faster than Python. If i was restricted in my choice between these two languages i would have written the services in PHP rather than Python (not only because of performance) even though i consider both to be bad choices for my requirements.
Because the servers will have to process a lot of client-server heavy operations. Because it was clear from the get go (when i wrote the technical specifications) that i will need to do some metaprogramming. Because i have to write some CLI utilities in addition to the backend servers. Because the project consists in a domain-specific niche ERP system which needs to be highly maintainable, extensible and readable.
All the aforementioned requirements are better served with Java or C# rather than PHP.
>not a single time Go was mentioned
Anon, I...
It does not make sense to use Go for writing this (
) kind of apps. I'd use go when i need to add to the software a real-time chat service between staff members or if i need to add a geofencing api for tracking product delivery. I'd use go for one or two i/o sensitive services (and even then i doubt i would take that decision and would rather stick to my current stack).
Go is simple but lacks so many built-in methods and features that i ruled it out in the very early stage. I don't want to reimplement features from scratch and i don't want to have hundreds of lines of if/else statements in my codebase. The environment also may not be large enough. In summary, using Go for writing such an application would involve a lot more boilerplate and productivity loss compared to Java or C#.
And that is why i avoided Go (but still, it's a great lang)
you want framework-level functionality but on a language level (which is moronic to want, because framework-level functionality still makes a language a framework-like)
Of course you come up with shit like ASP.NET. However you need Go + a tool kit/framework like gin or gorilla. Done.
Also, you say performance is important but say you only need Go for low-latency apps... Black person low-latency = performance. If speed is important everywhere you use go everywhere.
you seem unexperienced and optimising along the wrong gradients
My friend, abstraction made from frameworks, Java and C# have a large set of built in functionalities and methods that need to be rewritten from scratch in Go. And yes, i do need framework level functionality on top of that which neither Gin nor Gorilla serve. I would define Gin as a micro-framework or as a more richly featured routing library. The concept of exhaustive frameworks is in contradiction with the Go philosophy.
you underestimate how much a framework will slow your coding down compared to just using a language + tool-kit (if you are a rational human being)
code monkeys will be slow anyways. But anyone with an IQ > 120 will become slow and miserable using fat frameworks.
I beg to differ. It would be helpful if you provided examples and arguments to clarify your point. In my personal opinion, the problems you're talking don't concern all frameworks. They are true when it comes to opinionated framework that restrain what you can do.
I would like to take .NET as a case study since it's the technology i decided to use for the application. .NET is a highly modular (and theorically a micro-framework since it comes only with a built-in router) and an optional unified query language (LINQ). It can then be extended and customized.
Instead of writing my own prepaired statements and using parametarized SQL Queries, LINQ abstracts away this task, prevents direct SQL Injection attacks and servers as a unified query language for all database systems, xml/html, object parsing and more.
The framework also presents a set of datatype annotations to verify and validate some datatypes like email addresses, phone numbers, isocodes, etc... It also helps with internationalization issues.
EF Core generates a model based on my classes to which i can append all the constraints and optimisation tweaks i want. It also handles migrations for me.
The Identity Framework takes care of hashing, salting, logging, 2FA, third party identity providers, role and permission based authentication and is used by large institutions. It can be extended and customized at will. Things like versioning, caching or guarded routing are also extremely simplified.
These are only some very limited examples to illustrate my point. I would like you to explain to me how any of these slow down your development process. I see them as massive time savers. I can live without them and do all this from scratch but it just doesn't make any sense. Django or Laravel for example are bad examples of Frameworks that come with a large battery of libraries (most of which you will never use) and their opinionated nature represent a constraint if you want to do something out of the box.
>It is only true* when it comes to
>Also, you say performance is important
I said performance is equally as important as productivity, convenience, maintainability and readability. One might argue that Go's readability is decent, but i don't consider it to check the box when it comes to productivity, convenience and maintainability. I would spend much more time writing Go code and thinkering about the architecture of my codebase than i would in Java or C#. And for what?
>If speed is important everywhere you use go everywhere.
No. If speed is the only metric to take into account, you use Go or Rust everywhere. I very explicitly specified that i need balance between productivity, maintainability and performance. There is almost no performance gap between a C# webserver and Go webserver. In many cases, it's the other way around. I took a chat application as an example of a program that is perfect for Go because the scope of the software is limited and thus more straightforward to write, and because it would involve real-time concurrent websocket communications which is the exact problem Go was created to solve.
>The hard part is deciding what the desktop application will be built in.
If you don't want electron, how about Qt? You can use Python if you want to avoid C++, it's cross platform, it shouldn't be too bad. But the licence may screw you over if you're looking for something free...
Apart from Qt and Electron, there's JavaFX and that's about it for good cross platform GUI frameworks. No idea what else remains, like GTK is dogshit when it's not on linux, WxWidgets are not quite great and I can't name any more cross platform GUI frameworks.
Out of those 2? C# is better.
Explain yourself anon.
not him
>much tighter and cleaner syntax
>much tighter and cleaner eco system
its like MS look at java, looked everything java did and said
>that's pretty cool
and made something better
no maven/gradle bullshit
no lombok bullshit
and no other third party bullshit
it just works so well and I hate it. I have other friends in backend shit and they hate it for the same reasons. no hibernate dao and repos or spring throwing fits because B E A N S
you load up visual studio, you write your linq queries and you get stuff done.
that said, you are sucking huge MS dick at that point. Almost everything you use is either Microsoft branded, Microsoft developed, Microsoft supported etc etc
Yep. That is partly why i went with C# rather than Java. It was the hard decision to make. The advantage of the JVM environment vs the convenience and productivity of C#. To be able to make that decision i first extended my technical specifications and made them more detailed, then i searched for all the dependencies i might need and looked at their licensing to make sure i would have no issue with Nuget (libraries missing or being paid).
There is however one thing i did not think of, which is limiting the number of vendors and the use of the same language for my desktop client. If i took that into consideration i might have decided to choose Java instead simply because the desktop-first frameworks in C# (MAUI is a mobile-first tool that is not mature yet) cannot run on Mac.
>it just works so well and I hate it
why hate it if it works so well
because its tied into MS
Microsoft, Google, Facebook, Oracle. I don't care about that. As long as the language/framework is regularly maintained, updated, optimized, as long as the vulnerabilities are quickly dealt-with and patched, as long as it's package manager offers a solution to every problem i might have, i don't have problems using it.
This. If you're running in house and fine with MS then C#. If you're going to be selling the service you'll want Java. My experience is with Java but I've heard C# is more comfy. I have no reason to disagree with that.
This
IMHO, if you can afford the costs associated with .NET, use it (it’s not cheap). Otherwise, stick with Java (it’s free).
>.NET, use it (it’s not cheap)
How is it more costly than Java?
ps: any other answer involving any language designed to be system-level first and foremost will also be discarded
Ops pic is hilarious.
As if writing php is harder than messing with flexboxes to make it look good on all devices, doing animations, interacting with the php, etc...
Well nodejs nowadays or whatever.
No my friend. You are moronic. Not does the pic i i took randomly from Google to meet the media requirements for posting a thread stating that the backends are more repetitive and involve more effort (not that they are harder), but working with flexboxes is the easier thing on earth. Animations are a bad idea in 90% cases and they themselves are easy and can be done in 90% cases with CSS only using transform and transition properties. I can say by your moronic post that you only worked on fizzbuzz projects or meme projects with barely any business logic needing to be handled. Backends involve way way waaaay more work than frontends, and i'm good enough with both. And when i say frontends, i'm not only talking about web frontends but also mobile and desktop.
>Not only* does the pic
>state*
>easiest*
(sorry for the typos)
i need to:
>Create a CLI utility to generate custom projects for client backends and their frontends depending on their requirements
> Build an automated mailing service (mail transporter)
> Generate legal documents and invoices based on the data fed to the server
> Track orders at different stages of completion and track warehouse inventories
> Log employee and manager actions on the system
> Create analytics about a different set of metrics like default rate and rate of completion of product manufacturing
> Transaction processing with different pricing methods
> Multi-factor Permission based and role based authorization methods.
That's not an exhaustive of course. Do you really think the work that will be done on the frontend is comparable to that on the backend. The frontend will be a data oriented UI with a lot of guarded routes and a lot of lists and tabs, but still, it's not comparable.
Ignore
This moron has never coded backend in his life.
> Build an automated mailing service (mail transporter)
Hangfire + System.Net.Mail
> Generate legal documents and invoices based on the data fed to the server
Try cshtml
> Track orders at different stages of completion and track warehouse inventories
Idk
> Log employee and manager actions on the system
Serilog
> Create analytics about a different set of metrics like default rate and rate of completion of product manufacturing
Idk
> Transaction processing with different pricing methods
Idk
> Multi-factor Permission based and role based authorization methods.
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/mfa?view=aspnetcore-6.0 + JWT
Yeah, i'm already experienced enough with the .NET environment already but thanks a lot for the good tips anon.
You may want to read this:
ELIXIR + PHOENIX
COME HOME WHITE MAN
This.
Correct. Phoenix Liveview is too good + elixir makes functional programming doable for pragmatists.
If you're new to elixir, deploy on fly.io. And build ElixirLS by hand, or "intellisense" will not work. Cringe ass tooling
Erlang/Elixir/Phoenix are on the top of my list of technologies i never tried and am very interested in. I hear a lot of good thinks about them. When i get the opportunity (when i have more free time) i will definitely try them out.
Great to hear. Bookmark this for when u find the free time. I suffered for too long without autocomplete properly working, learning phoenix. I can only imagine how many other souls are still suffering, unaware shit is wrong
https://dragoshmocrii.com/fix-vscode-elixirls-intellisense-for-code-imported-with-use/
>Great to hear. Bookmark this for when u find the free time.
Done! Thanks for the useful tip.
bash
The fact that most modern developers only know how to do node backends fricking kills me.
Do westerns really?
php7+
php with laravel 9 and python api for scripts
Unironically Clojure
>any answer involving Rust or C/C++ is de facto discarded
im writing a frontend in pure html/css and a backend in c++ and its going well
For you maybe. It's not a wise choice for me given the size of what i am building and the resources i have at my disposal. I need to move fast enough. Productivity, convenience and maintainability are equally as important as performance. I had no reason to even factor C++ or Rust in my benchmark. JVM langs and C# were the only viable option (in my opinion).
>Productivity, convenience and maintainabili
yes c++ has all three
Anon, i took part in building C++ software in the past. That is simply not true. Not when compared to JVM langs and C#. That is definitely not where C++ shines and the gap is not marginal (it's significant).
noob
My post wasn't meant as an insult but okay.
sorry im just half-shitposting
Yeah i know. But i do like C++. I might use it for the desktop client since i can't think of an appropriate solution that can run outside of Windows, that doesn't have issues with UI rendering and that can be performant, and that isn't a ram-hungry glorified mobile app or web browser in disguise (yeah i'm thinking of flutter desktop and electron).
nginx
wat?
Rust or C++... or Python. Wouldn't recommend Java, but that's because I hate Spring Boot.
>But Python is slooooooooooooow
On any webstack network latency is going to be an order of magnitude more than any computation you need to do.
Read this:
x86-64 assembly
I see, the trolls finally arrived.
rust go
no
In todays world of web development this figure is untrue. Shows that OP has no actual work experience. In most companies I would even say the ice berg is upside down.
Todays modern SPAs utilise client-side computation as much as possible to minimise the computation-bill payed for the backend. Any Tech Lead nowadays will try to design the app so that as much computation as possible is off-loaded to the client.
Since i am tired of repeating the same thing over and over, i'll refer you to this:
moron I was writing about JS not about CSS. Not talking about formatting but about actual business logic written in JS in frontend
>backend: repetitive
>frontend: not repetitive
Yes, I'm sure copying the fotm flexbox and adjusting it to fit an phone screen for the 100th time is not repetitive work.
If you're doing it this way, you're doing it the wrong way. I'll suggest you forget anything you know about styling and relearn everything from scratch. You have horrible habits.
>just install the latest vanilascreenmango papaya framework version 12.0 and learn to use yet another library that will be abandoned in a month
No dude. I don't use CSS frameworks either. The assumption that they provide a productivity gain is just that, an assumption. If you write your CSS code properly, it is highly reusable throughout your app (provided that you already have a clear idea of your design system and your components layout prior to starting to code). And if you apply responsiveness properly (from mobile to desktop), only need to alter the very specific properties that need a change and half of the work is done through flex/grid.
That's false. If you use jss you'll only need one button and pass arguments or props to it
>I'll suggest you forget anything you know about styling
Joke's on you, I don't write css "code."
I'm sorry but making that cupcake fit in the corner of that box when somebody scrolls through the cellphone is harder than making a login form.
I just want to use Ruby
Rails has ruined it though
>Has question but the answer cant be anything his peabreain cant handle
Scala, erlang
Easy: Serverless stack in typescript
Hard: Rust/Go microservice
Depending on requirements. As of lately I mostly use API GW + Lambda + SQS + StepFunction (have lots of small lambdas to compose as I wish)
Do you really need to use AWS?
Yeah, we already have everything there
Isn't it too overengineered and convoluted with all the set of services you have to glue together? I feel like it's better for the very large corporations.
Not really, it cuts down by a large margin our time spent on maintenance (managed services) and development (we reuse a lot of stuff)
I would recommend serverless to anyone, truly comfy. Vendor lock in and latency (~100ms on cold start) are the only issues.
>latency
Yeah, it's really a serious problem when you use VM based, garbage collected JITed languages like Java and C#. Serverless is better for things like Go.
>would recommend serverless to anyone
I think it depends a lot on the kind of services you have. Serverless might end up costing you much more at the end of the day.
I made an estimate some time ago for the higher ups, and break-even came at about 20 req/s, excluding dev/ops costs
PS: 20 req/s constantly 24/7 for a month. So for not so big APIs or scheduled stuff is almost free
for modern websites the pyramid is inverted tbh
Depends on your project. Most serious projects still have a much larger backend. Even with Nextjs+Reactjs+TailwindCSS+ReduxToolkit+ThreeJS stacks.
Php is pretty comfy. Sure the language kinda sucks ass and is inconsistent with some naming conventions, but it just works.
Sir use django no problem
Django too much. Use WordPress sir.
>repetitive
>web devs haven't discovered loops yet
Just when you think they can't get any lower...
Oh my... we have a very special kind of moron there guys...
Go one then.
Show use your for loops, you do have them... right?
>He posts a foreach stream operator
Kek
>stream
POO. IN. LOO
In most cases for loop will be mutating state or causing side effects. Using a foreach loop is better in most cases. If not, consider using the StreamAPI, LINQ or other functional constructs are a better alternative.
>since they are*
Alignment and bracket placement are a bit funny, lines are too long.
Two nested calls to .Any could be replaced with a SelectMany and an Any, which would reduce nesting.
t.ClrType.GetProperties().SelectMany(p => p.CustomAttributes)
.Any(a => a.AttributeType == typeof(DatabaseGeneratedAttribute))
Any reason why you are not using tuples here?
Or map for that matter.
public async Task<List<(string name, string value)>> GetLegalIdentifiers(string legalName) {
//...
return uniqueEntityIdentifier.Select(item => (item.LegalIdentifier.IdentifierType, item.UniqueIdentifier))
.ToList()
}
The alignment on that last . is just criminal.
The logic here is also beyond screwed up. You write the same thing twice and don't put it in a variable.
You could easily reduce nesting with a guard (though it would be much harder if you didn't understand loops).
The question mark operator makes half of this trivial.
foreach (string indicator in indicators) {
var isValidString = addressObject.Where(x => x.Key == indicator).FirstOrDefault()?.Value?.ToString();
if (!string.IsNullOrEmpty(isValidString) && typeof(Address).GetProperty(indicator) != null) {
addressObject.GetType()
.GetProperty(indicator.First().ToString().ToUpper() + indicator.Substring(1))
.SetValue(address, isValidString);
}
}
Based LINQ enjoyer absolutely BTFOs imperativelet
how is linq different from java stream api?
Why would I know, I don't write Java.
less verbose
>"muuh verbosity le baad"
.
>Task<List<string[]>>
Oh shit Black person what the frick are you doing. Also mixing data access and business logic? That's some fine spaghetti you got a brewing there.
>Also mixing data access and business logic?
What? That's a method in a repository pattern that takes a relatively complex dataset of related entities, formats it and makes it accessible so that it can then be mapped to a DTO and sent as a response through a controller.
If you have array[0] , array[1] somewhere in your mapping code for the results of that query I would literally fire you on the spot. But I concede that there's no business logic, I didn't bother reading it thoroughly I just assumed so by the sheer amount of code. Alas it was just because it was shit code.
You sound like a first year junior who was just given a design principals article. Go frick yourself, LARPer.
sore spot?
>first year junior
He's not the one using string[] when he wanted Pair<String, String>
That's also moronic. The proper return type in a case where there is a list of arrays of type string with a key and a value pair should have been a JSON Object.
>Json object
>anywhere other than application boundary
>If you have array[0] , array[1] somewhere in your mapping code
No i don't have that and i don't need it, the mapping is simple and all the work is done in that method i showed you. The data is then displayed in another application in a table. My only mistake here was the choice of the return type (which you weren't able to notice). What i should have done (preferably) is return it as a JSON Object.
> But I concede that there's no business logic
Yeah
I have been recently leaning towards doing that precisely. I think that using an ORM and EF in particular is already having a repository (transactions, etc.) and that I hardly ever need to reuse a particular repository method in more than one place, as the data access is closely related to the business logic if you also want to have some performance.
Jesus frick. Define an extension method on UniqueIdentifier
public static IEnumerable<string> ToLegalNameAndValue(this UniqueIdentifier uid){
return new []{item.LegalIdentifier.IdentifierType, item.UniqueIdentifier};
}
And do
//stuff
return company.UniqueEntityIdentifiers.Select(ToLegalNameAndValue).ToList()
instead of the frickfest you're writing.
we in the age of the frontchad now
The only real choice, if I were a CTO, is .NET or Java. I personally prefer .NET, and find it more modern after .NET Core. It will give you a comfy language, well-established frameworks, and well-established libraries for everything you may need. And tons of resources and help, as well as easy to hire people.
Now, as a developer, I would go with a more modern "flavor of the year" stack. Which right now, is Node or Go, most likely Go, as Node has attracted an enormous flock of mediocrity. That way, you can ensure that you work on new projects and do not end up maintaining and trying to refactor a big mess of code made by pajeets. But then, you will find that you need to reinvent the wheel quite frequently, and that digging a little bit under the surface of even the major libraries (e.g. some non-usual requirement), they easily crumble.
Node
One reason that beats everything else: universal SSR. There is simply no other language/framework that allows you to build both client side and server side rendering using one code base.
But that's just for website backend. If you are making just an web API without front end, you can really just use whatever you feel comfortable with. Be it C#, Java or anything enterprise friendly.
>There is simply no other language/framework that allows you to build both client side and server side rendering using one code base
You need a proper introduction to ASP.NET Core anon.
Introduce me then. Show me how you write client side rendering using ASP.NET Core.
https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-6.0
That's just SSR with extra steps. It's slow, resource intense and if you want to write anything non trivial on client side you will have to mix it with JS which is the problem I am talking about.
That's not what I am talking about.
I am talking about having one code base that is both responsible on initial server side render and then can just work independently on client side as SPA, and eventually requesting some data from apis when needed. Every foreign language compiled for webasm will always be heavily limited and require JavaScript mixins to do anything non trivial.
Tell me one case where npm caused you personally a problem and it wasn't a result of you doing something stupid with it.
>I am talking about having one code base that is both responsible on initial server side render and then can just work independently on client side as SPA, and eventually requesting some data from apis when needed.
And i understood you. That is possible with Blazor. Blazor WebAssembly apps don't require a server to execute server-side code in order to download and run. Blazor WebAssembly apps can be delivered via a Content Delivery Network. You can also combine both practices.
>if you want to write anything non trivial on client side you will have to mix it with JS which is the problem I am talking about.
You don't have to write a single line of JS. You almost never have to use JS Interop. Why don't you try it first then share your thoughts about it?
Friend of mine has shown me it some time ago and that's what I've noticed.
But fine, I'll check it myself then.
Aren't you talking about Razor?
In a few months, Blazor will take a gargantuan performance boost. For now the framework runs on a single thread and requires the download the runtime to run. In a few months (in .NET 7), Blazor will take advantage of multithreading and run without a runtime thanks to AOT (can also mix AOT and JIT).
By using Blazor which is the most widely used WASM framework. You can choose between server-side rendering and client-side rendering depending on your needs.
In the client-side model (Blazor WebAssembly), the Blazor app, its dependencies, and it's runtime are downloaded to the browser, and the app is executed directly on the browser UI thread. All UI updates and event handling happen within the same process.
That, with the obvious added benefit of having a proper, reliable and rock solid backend stack instead of using Node.js and having to deal with NPM.
Java does that sirs
>Java does that sirs
Ok, show me how you write client side rendering using Java.
Swing? Idk
I use Go, its web backends are practically what its built for
Go is unironically better for CLI utilities, for writing stuff that runs on background processes and for creating malware than it is for regular web needs (i consider highly concurrent real-time i/o to be a non-conventional requirement).
Isn't concurrent I/O how a webserver works?
>Repetetive
Do javagays really?
>front end is 20%
not with these all over engineered frameworks lmao
>backend effors is 80%
lmaoo you can setup db easily or even use a cloud one, and make the driver for it with few line of codes copy pasted from docs.
10 years ago this pic might be true, nowadays it's the other way around.