APIs in Spring

[Kanika Sud]

What would be the alternatives to gRPC and GraphQL with REST in Spring Boot? And How is the choice governed in business situations?

Is Spring API code a good choice for SMBs? Considering that SMBs run on shared hosting, and mostly choose PHP?

Compared to the Enterprise culture that chooses Java, the smaller agencies go for an everything Javascript approach. Your comments?

[Tim Holloway]

It used to be that a lot of SMBs ran their least expensive services on relatively weak VMs with little RAM. No problem for LAMP servers, but Java is pretty hungry.

These days, however, even the bottom tier can generally run Java and some (such as Amazon) actually have special services for running stuff like Spring Boot or Tomcat instances.

Spring itself has many Modules, so you can use as many or as few of its API's as you need.

As for JavaScript, the more I work with it, the more infuriated I get. Bad enough when I was just struggling with getting it to determine the difference between a null string, a null object that was supposed to be a string an empty string, a blank string and so forth, but I've been using NodeJS to to my quick-and-dirty webapp servers and the infinitely-deep stacks of callbacks that come from not having a civilised threading architecture are really beginning to get on my nerves.

Any enterprise of any size, however, is likely have a mix of technologies, not only Java and JavaScript but Python, maybe some Ruby and .Net.

[Rob Spoor]

Tim Holloway wrote:As for JavaScript, the more I work with it, the more infuriated I get. Bad enough when I was just struggling with getting it to determine the difference between a null string, a null object that was supposed to be a string an empty string, a blank string and so forth, but I've been using NodeJS to to my quick-and-dirty webapp servers and the infinitely-deep stacks of callbacks that come from not having a civilised threading architecture are really beginning to get on my nerves.

Callback hell is definitely something to stay away from as far as possible. There's a quite promising ( ) alternative, but of course the API needs to support it.

I recommend using TypeScript instead of JavaScript, as it makes it clearer (at least to me) what everything is. I especially had problems knowing what "this" is at any point of time, but TypeScript will just tell you.

[Tim Holloway]

Where I really got my wrath aroused was the Node sqlit3 package. It's ALL done in asynchronous callbacks even though the actual low-level functions are synchronous and blocking (just like in JDBC).

There's an alternative "better-sqlite3" which deals with sqlite synchronously, but it requires installation of a raft of C++ build tools and it won't build clean on CentOS 7. So that blew away the "better" part for me.

[Sourabh Sharma]

Java 17 is optimized for performance. App running on Java 17 JVM can be light-weighted (if you package your artifacts intelligently). Spring boot can run on embedded web servers such as Tomcat/Jetty. Therefore, you don't need to install the webserver separately. Running your backend is straightforward such as `java -jar <path>/<app>.java`

Choice of technology should be considered based on functionalities and load rather than based on the organization size. If you think you might need to scale in the future then JVM based solution is the preferred choice.

gRPC should be preferred if you have more than 1 service deployed in the backend and these services communicate with each other.

GraphQL should be preferred over REST if you have a plan to serve handheld devices to optimize the number of calls.

You can use one of the samples from https://github.com/PacktPublishing/Modern-API-Development-with-Spring-and-Spring-Boot in your VM box to check the performance.