Daniel Oh

Cool. Thanks for sharing!

Thanks for sharing it, Patrick! If anyone had a chance to attend at SpringOne this month, you got a bit more details on how Spring Native is going. According to VMware statements, Spring Native will be fully supported in Spring 6 (expected GA is late 2022). I'd say why you just start with Quarkus for native compilation rather than waiting for at least 1 year :)

You're right. For Quarkus, you can find all dependency libraries here: https://code.quarkus.io/

I can't still agree that VPS can solve all business problems and is a cheaper maintenance cost than serverless cloud. It will vary business domains, workloads, seasonality, topology, human resources.

Thanks for sharing your thoughts. I agree that cost is always important to manage the business but I disagree traditional infrastructure(VMs) can leverage all workloads for scalability, performance, reliability. Also, serverless is not "cloudfull" but the serverless functions should be scaled down to zero when there's no demand at all. It means all relevant resources are free then you don't need to pay for that. If you have bad experiences with serverless, esp cost stuff, I'd say you need to optimize the application first to fit in Serverless architecture. What language, framework, package do you use to run functions on the cloud? If you have Knative on prem Kube, you can build your own serverless platform as well :)

Thanks! Node means Kubernetes worker node. HotSpot box means Java which is the lowest density to run app pods.

Yeah, native compilation will be one of the next topics.

Stay tuned! It will come up soon :)

Thanks, James! It will come soon!

When you run the Quarkus development mode(i.e. mvn quarkus:dev), you don't need to recompile, rebuild, repackage, restart runtime whenever you change code since Quarkus does it automatically which means developers can save time for those jobs.

Quarkus already support native compilation when it was designed. Sure, I'm also looking at Spring Boot Native which is still beta and needs to be optimized for production. Thanks for the comments ;)

Sure, you can. If you have compiler cargo in your .vim/ftplugin/rust.vim, you can do :make <cargo cmd>. For example, :make build will run cargo build. See here: https://github.com/rust-lang/rust.vim

Good catch, Kelvin. Thanks for letting me know it. I just fixed it then it will be revised soon enough.

I can't say to agree 100% but I would say that no matter how well you designed the REST API dataset, structure, the over-patching or under-patching always can be happened since clients need to call several APIs to retrieve the required data or even don't find out the appropriate APIs. Once again, GraphQL is not a replacement for REST API specification but merely an alternative. Unlike REST, GraphQL APIs have the ability to benefit the client by Preventing Over-fetching & Under-fetching and API Evolution since GraphQL APIs returns data that is requested by the client adding additional fields and capabilities to existing API will not create breaking changes to existing clients. Thank you for your thoughtful comments.

Are you saying that developers(client) can avoid under-fetching and over-fetching data when retrieving data using REST APIs?