31–40 of 213 posts
I would not start with technology stack and build around them. You look at your use cases and build out. Pick your frameworks and databases judiciously and as late as possible. Read: https://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html Read: http://www.amazon.co.uk/Growing-Object-Oriented-Software-Gui... [EDIT] Removed the unnecessary/unhelpful opening statement.
Grails, I really like Groovy as a language. Grails provides a lot out of the box and is good enough performance wize for small to medium sites with no tuning.
i recently wrote a small blog engine in vert.x ( http://vertx.io/ ). i'm not fluent with reactive programming yet (so i didn't use RxJava), but the callback hell was manageable enough. among the upsides are the seamless integration and handling of websockets. the blog engine is a bit of an outlier though because it's embedded and fully single threaded. there are a lot more advantages if you leave out the embedding, l…
But only because I'm used to nodejs and this is the jvm equivalent.
That would be Spring Roo, along with roostrap. http://bhagyas.github.io/roostrap/ and http://projects.spring.io/spring-roo/
I would not start with technology stack and build around them. You look at your use cases and build out. Pick your frameworks and databases judiciously and as late as possible. Read: https://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html Read: http://www.amazon.co.uk/Growing-Object-Oriented-Software-Gui... [EDIT] Removed the unnecessary/unhelpful opening statement.
Frameworks and stacks provide templates for building CRUD apps. Building CRUD apps (read: database skins) isn't a big technological challenge most of the times anyway. So picking a stack that abstracts most of it for you could be a great help to only focus on the parts you care about.
Not every project requires astronaut architecture and grand design. Half the internet runs perfectly fine without these considerations.
Scaffolding a project through the tooling of a framework (tooling matters!) and having something up in a day instead of philosophical debates about your data is huge. Having something up in production super fast because you didn't stop to think about architecture is perfectly fine for 95% of software projects that are just CRUD.
Then on the client side you can add some hype using React or what's hot at the moment. Joke aside, on the server side Spring is solid, the whole thing is well engineered and it got you covered on every aspect of this kind of app, and then more.
https://www.youtube.com/watch?v=7dsX0S0WsEk
If Scala is not your thing, you should definitely check out Vert.x 3 with vertx-web https://github.com/vert-x3/vertx-examples/tree/master/web-ex...
Spring Boot backed with Postgres and Maven to wrap it all up. Spring Boot is really years of distilled knowledge of creating web servers in Java. Its opinionated but for good reason; you'll very quickly get everything you need for a RESTful API and there's extensions for almost everything you'd need. Need to work with websockets? Just add a few lines to your POM. Need scheduling? Include an annotation on your main cl…
I would not start with technology stack and build around them. You look at your use cases and build out. Pick your frameworks and databases judiciously and as late as possible. Read: https://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html Read: http://www.amazon.co.uk/Growing-Object-Oriented-Software-Gui... [EDIT] Removed the unnecessary/unhelpful opening statement.
We know nothing of OP's case so the best thing we can do is trying to answer his question instead of answering to go read some lengthy book.
OP might be in a team that needs to develop an API for a product that will be deployed to millions of people(I doubt it) or could be someone that just wants to know what is the current fashion to develop a CRUD application while learning a new stack that is up to date.
In the first case, you might want to learn more of the situation you are in and pick around that. In the second case, there is nothing wrong with just picking one and hacking away.