Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I recently started working for a company, which has outsourced all their IT business, due to several reasons. After a few years, they've started to realize that they are constantly overcharged by some of their external partners, leading to the point where they finally decided to bring in some IT expertise to evaluate possibilities to consolidate their IT costs.
This is where I came in. After now working for 3 months in this company, my boss has suddenly offered me the possibility to re-implement some of the software, which they are currently using as a service provided by an external partner, which would take over starting 2018.
After taking a closer look at what this current software does & how it is set up, it is really incredible what this external partner is charging them for the service, so I'm really tempted to consider the offer for re-implementation. I already gathered some experience with Spring, Spring-MVC and partly Spring-Webflow, setting up a small web-application using a relational database through hibernate (although I wouldn't mind using any other Object-Relational-Mapping as well).
The question that arises now to me is, if I completely overrate the possibilities which Spring is giving me. Upfront now some of the requirements and small description of what the software needs to be capable of:
Web Application based on a relational database server
10.000 users maximum, the daily access to the system is around 100-200 users only(!)
Several roles (admin, manager, customers, end-users) with different views & workflows
all in all several different workflows for each role
the workflows are all based on data only, no heavy calculation or other complicated stuff, really small straightforward workflows of a typical small web application
several smaller interfaces to export/import data, typically provided or delivered via XML/Excel/CSV files
standard security/logging features
As far as I can tell, all this requirements could be easily fulfilled implementing this project as a Spring-MVC/WebFlow application, using the aspect-oriented security/logging approach of current Spring versions, with any modern RDBMS working in the background.
Right now, my company is paying 5-digits numbers per month for the use and service of this system (which by the way is a standard-product from that rather small external IT company, only issue is, that there are barely no other software products in this branch by other companies), while still having to pay a lot of money on top for every small change (minor changes to the workflows, changing text on existing pages).
So this is really a very tempting offer, since the software requirements are rather standard from my point of view, and in my opinion, Spring would provide a perfect base for such an application.
My main question is, am I overlooking something in the here stated requirements, which are not feasible via Spring.
Thanks ahead for any input regarding this topic, while I continue my evaluation of it by myself.
Taking a look at your requirements, I don't see anything in there that you couldn't reasonably easily implement using the Spring stack.
A few things that you haven't mentioned:
Start by using Spring Boot. It will vastly simplify the configuration you need to get up and running with Spring.
It would probably be best to use Spring Data JPA in order to handle most of your persistence needs (since as you mention you will be using a relational database)
You security and roles needs will probably be met by Spring Security.
Here is the code of the Spring.io website which is a real world site using the latest Spring technologies.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 months ago.
Improve this question
I am currently learning Spring Boot.
My project is to create a RESTful API and a webapp at the same time. They both connect to the same database.
I think that a good practice would be to separate everything that is related to the API service from the webapp. In other words, separate back-end (controllers that send only JSON data) from front-end (controllers that send web pages).
If so then what would be the proper way to do it? Create two projects and run them simultaneously? Create one project with multiple modules?
The tools I am using are: IntelliJ, Maven, Spring Boot, Thymeleaf, H2 database.
--
Currently I divided my project by 3 modules : core, service (for API) and web (for webapp).
I don't know if I'm going in the right direction with this structure and would like some advice before I continue.
I hope my question is clear enough and if not, then I will edit it.
I think your question is more about possible architectural approaches than concrete implementation details.
The answer IMO is "it depends".
If you build something small and easy - there is no point in separation. Keep the code in different packages in the same module, or if you wish to have more "clean" separation - create maven modules for frontend and backend, package them together and you'll end up running one single application.
Spring Boot is a "runtime" framework - so it doesn't really care how do you organize the code as long it follows spring boot's conventions.
The advantage is clear: Less hassle around deployment.
Now, imagine, your application has grown a lot, so you think about scalability, you need more developers to evolve it.
Then you measure the application performance and come to conclusion that the backend part is way busier than the frontend part.
So you would like to keep, say, 10 instances (running processes) of the backend and, for example, 3 instances of the frontend server. In this case you might want to start separating to two different servers.
Then you have two different teams of developers - one is around frontend interaction and another team can write beautiful queries to the Database but do not know much about the frontend. They want to roll the releases separately, use different dependencies, etc. Well - yet another reason to separate these two projects.
There are many more arguments of why would you consider separation like that. But bottom line as long as your project is small - keep it simple, sometimes its way more convenient. For bigger projects that have significant load, different performance guarantees, use different technologies under the hood - I would say, consider the decoupling.
One technical note about the spring boot. Its a "single-JVM" centric, so it won't help you to make such a decoupling. Usually you'll need to maintain two different modules of spring boot applications, list of dependencies, plugged-in technologies and so forth.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am making an API with Spring boot which will maybe have requests peaks.
So let's get into the worst scenario. Imagine that suddenly I have 2 million API requests.
What can I do to be able to handle this?
I read something about queues and workers but I don't know if that's the best way.
Is there some way to do it with something with AWS?
This is always a tricky question to answer. Firstly does your app really need to scale to 2 million API requests at peak? I ask because it is easy to over-engineer a solution 'to deal with future scale' which ends up a bit buggy and not even dealing with current scale very well as a result.
But assuming you really will have massive request peaks, the current microservice approach (or buzzword?) is quite a popular way of dealing with these periods of high demand. Basically you split your application up into smaller, self contained services ('microservices') which can be more-easily scaled as required.
Individual microservices can then be scaled up and down to match the load, using something like Kubernetes or Amazon ECS.
In terms of where Spring ties into this, Spring has a handy set of technologies called Spring Cloud - you'll notice Spring Cloud AWS there, too (although Spring Cloud in general can also work fine on bare metal servers, Docker, Kubernetes etc etc). A year ago I put together a simple Spring cloud/microservices demo on Github which shows how different Spring-powered microservices can fit together, which you may find useful.
The other nice thing with microservices is that you can swap out the language that a particular service is written in fairly easily, especially if the microservices 'speak' to each-other in a general format (such as JSON via REST requests). So if you had 10 different microservices, all powered by Spring Boot, but you find that a couple of them are better written in another language, you can just rewrite them: as long as they send and receive data in the same way, then the other parts of your system don't need to care.
Okay, that's a lot of buzzwords and new concepts. Feel free to ask questions if I can clarify anything, but microservices + kubernetes/AWS is a popular solution.
Other approaches which will probably work equally well, however, are:
Serverless - this is where you use a bunch of cloud-provider's tools and solutions to power your webapp, including things like lambdas, instead of hosting your application on a traditional server/VM. This medium tutorial gives a simple introduction to serverless.
Monoliths - this is a traditional web application which is a single, large, sprawling codebase, but this doesn't mean you can only have one instance of it running (i.e. you can still scale it). This very site is a successfully scalable monolith.
Your question is very broad, as there are lots of different solutions:
1) Use a load balancer and have multiple instances of your application
2) Use a containerization tool like docker and kubernetes to increase the amount of instances depending on current load. You can essentially scale on demand
3) We don't know what your app actually does: is it read heavy, is it write heavy? Will users be downloading content? The answers to this question can change whether or not a specific solution is feasible
4) You can maybe use a messenger queue like RabbitMQ to assist with distributing load across different services. You can have multiple services reading from this queue and performing actions at the same time...but again, this depends on what your app will actually be doing.
Check out AWS EC2 and Elastic Beanstalk. You can also get a simple load balancer up and running with nginx. Good luck
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm starting a new web based enterprise application, and I'm thinking of using Wavemaker.
I'm a fairly experienced java-ee developer, but it seems to me that even in this case, WaveMaker still makes sense to develop the application fast and focus on the business logic.
My questions are :
1- Are their any drawbacks to this platform
2- Can I do all the normal things from the server side easily (like sending mail,building birt reports, adding jobs)
3- Can I freely manipulate javascript (for example for specific animations, using plugins....)
4- Can I integrate realtime processes, like websockets ?
Thank you
I've used Wavemaker in an Enterprise application with success. We used quite advanced features such as heavy use of backend logic based on JavaServices, an run-time SQL database selector made inhouse, JS plugins for the frontend, obfuscation etc
We later recruited a devteam to take support of this application and, although the community is small, the team learn quickly and was able to maintain the code base.
As I see it, Wavemaker is a excellent tool if you like to:
deploy a web-based CMS for your midsized SQL database
deploy a smaller web control page for your java back end system
To answer you questions:
1) Small community: Although the community is friendly and on their toes, it is too small to ensure the type of feeback you might be used to. You will have to spend quite some time banging your head to the wall when you try to go beyond the example applications.
2) Yes, you have all the freedom you would expect from a Java backend. Simply said; each REST api is assigned to a Java Method, its up to you to implement the logic. I have built wavemaker on SQL, mongoDB. With email interactions, data parsing, file upload/download etc You name it
3) Yes, you can add JS plugins and customize the scripts generated by Wavemaker. You might want to make sure that you don't edit the auto generated JS, since they will be overwritten. but as soon as you found the right entry point you are free to customize just the way you like it.
4) Yes, since you build you own back end in java you are free to open up any type of communication you like to have. And since you are able to customize the front end js you will be able to read this data. But as I said in question 1 - there will only be a small community helping you
So to sum it up:
I vote for Wavemaker, but make sure to only deploy it if you application will be similar to the templates/demo provided, if you build a unique system you might like to look into other solutions.
All choices have drawbacks. There is not a lot of WM expertise to be had. You'll need to deal with some issues in terms of the library at hand, dojo, spring etc instead.
you can,but it requires some java knowledge. You are operating in a spring MVC you can
you can, you are operating in a dojo client there
possible, probably. worth the effort, doubt it.
1- Drawbacks- It's enterprise focused platform, so will require own effort to learn it.
2- Yeah, you can do pretty much all normal things (at least from my experience, till now)
3- The tool has kind of open-source configuration so its easy to manipulate or customize your codes if needed
4- From my experience, WaveMaker has one of the best and most diverse integration options available.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
It's been a while since I've done any website with with Java, and am wondering what framework options are out there for Google App Engine.
What framework would you suggest for someone who has no real preference?
I like Ruby On Rails, and am getting into Django, and like that as well. Professionally I'm a ASP.NET developer so I have the most experience with that, but I'm looking to expand into other technologies, and patterns.
It would be nice to have more experience with MVC.
thanks,
Mark
The Spring Framework works, although you have to make sure commons-logging isn't called commons-logging-1.1.1.jar (as I had it in maven conventions, Google provides a jar with this same name and there are classloading issues as a result). So, Spring WebMVC is confirmed to work - which raises the possibility that its sister project Spring Webflow will work - though I can't say I really like where Webflow 2 completely diverged from Webflow 1.
Also, I have yet to find a framework that really encompasses the notion of "saving and continuing" well - users often like to do that, and Webflow 2 really tries to make programming that as difficult as possible if you use its persistence context inside the flows themselves.
Wicket works on App Engine, you just have to make a few tweaks to the configuration.
I've had variable experiences with Vaadin on GAE. Some applications are almost as fast as with localhost, but sometimes the latency is freakish. Probably depends on which server geographically your application gets deployed on.
Try ItsNat, more info.
Don't use it for a simple single reason - vendor lock in.
What happens if the service doesn't meet your satisfaction?
What happens if you can get a better deal (Java hosting) somewhere else?
What if you want to sell your product - where's your platform?
What happens if Google decides App Engine is not worth their effort and close it?
as a side note Google have and will close services that are unprofitable. A simple search will reveal many, escpecially in theses trying times.
Do you care about vendor lock in?
If you don't care about losing your effort and time invested and perhaps want a platform just to play with then I suppose it's OK but for anything serious stay away.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have not had much experience with Webservices or API's.
We have a website built on Oracle->Sun App Server->Java->Struts2 framework. We have a requirement to provide an API for our system. This API will be used by other systems outside of our system. API is just for a simple SP that we have on our database. The other system does not want to connect to our DB to gain access to the SP but instead and an API as a 'webservice'
Can the community please shed some light on how to go about this? Will the API be put on our webserver? is that how the other system will connect to it? And how to go about creating a public API?
Some things you'll need to think about are:
SOAP vs REST (Why would one use REST instead of SOAP based services?)
How will you handle authentication?
Does it need to scale?
You might want to take a look at https://jersey.dev.java.net/.
It would also be helpful to look at how another company does it, check http://www.flickr.com/services/api/ for some ideas.
If you are using the Sun App Server, it should be fairly trivial to make an EJB exposed as a web service with the #WebService tag, and then have that EJB call the Stored Proceedure and return the data. The app server gives you tools to publish a WSDL which is what they will use to know how to call you API.
That being said, what sounds easy at 50,000 feet is a real pain to deal with all the details. First, what about security? Second, are WebServices really required, or is there a better communication mechanism that is more obvious, such as (at a minimum) REST, if not some simple servlet communication. And the hardest part: In exactly what format will you return this result set?
Anyway, you could be dealing with a bit of a political football here ("what, you don't know how to do web services, everyone knows that, etc.") so it can be a bit hard to probe the requirements. The good news is that publishing a web service is pretty trivial in the latest Java EE (much easier than consuming one). The bad news is that the details will be a killer. I have seen experienced web service developers spend hours on namespace issues, for example.
Soap or Rest or .. is one side of the medal and depends on what the clients want.
The other (more) important thing is the api design itself. Shall it be stateless or stateful. Are clients co-located in the same VM (Appserver) or remote in the same LAN or even in a Wan.
As soon as the communication goes over the wire, it gets slow due to serialization. So you want API methods to obtain bigger (but not too big) chunks of data at a time.
Or in other words, your question can not really be answered without knowing a lot more about what you want and need to do.