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 11 months ago.
Improve this question
I want to create a catalog of java.util.functions so when I feed in A,B,C then the app will run those functions in the same order flowing the output to the next function?
The above statement is basic, which I would love to hear ideas. Eventually, the workflow will be fed an input as json for example to orchestrate this.
Also need to support reactor and where we can map, flatmap or filter.
For now all functions will be available in the project, and will be part of a Spring Boot app.
I am thinking, I can make the functions as beans, pull them and execute in order, although not sure how to orchestrate the functions in case there is a filter and then further if I want to use reactor where I will have map or flatmap.
Please share any ideas or any frameworks worth looking into.
Thanks
I think using a workflow orchestrator platform would be a great way to implement this use case.
You probably don't need that since all your functions are available in the same service, but using an orchestration platform will offer a lot flexibility as your service grows in complexity or when the need for orchestrating your use case across multiple services comes up.
An option for workflow orchestration is Netflix Conductor. Here is an article that talks about how to use Conductor to manage sequential tasks. Conductor platform has features to run flows in a distributed fashion as well, such as fork join, decisions etc. and this can be done across different services.
Ex: Service 1 hosting Function A, Service 2 hosting Function B and C. And you can build a flow running A -> B -> C while passing/referring to outputs from the previously executed functions without having to build any state management systems.
The above article was written as a response to this Stackoverflow question which is very similar to yours.
For clarity - I used to work at Netflix on the team that built and open sourced Conductor.
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 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 years ago.
Improve this question
My company has a poorly designed system that runs several services in WebSphere. The services currently communicate directly with each other causing poor performance. To address this, they have added several areas of multithreaded code throughout the services that make up the system. I realize that this is not the best solution.
Now, the company has decided it's time to move to a more modern set of tools, and we will be migrating all of these services to run in Docker containers managed by Open Shift / Kubernetes. (I hope I'm saying that right)
My worry is that all of this multithreaded code is buggy and difficult to maintain. I'd rather use a Messaging type of design that eliminates a lot of our service to service communications.
Can someone with some experience in these areas give me some good talking points as to why it's a bad idea to implement your own multithreaded code in the environment like the one we are moving to?
I cannot think of any inherent downside of running a multithreaded application on a single JVM instance (which is what a Docker container will translate) regardless of the environment. A lot of Frameworks, like Spring are already multithreaded.
I must say that your problem statement is a bit too broad to identify what you need help with, but, herewith nonetheless: I get the sense that the concurrency implementation in the application itself is the main concern here. In that case, I would say first look at the dangerous multithreading violations like race conditions, thread starvation, deadlocks, objects that are not Thread-Safe objects, etc. In my experience, these are some of the underlying issues with multithreaded applications. Once these are fixed, there should not be any reason to worry about moving to a different runtime environment like a Docker container, etc
Personally I think you should migrate your application to container format firstly as it is. It's more difficult than our thought in real work.
Yes, it's regardless of multithreading.
First step (most important) : migration of application to container as it is.
Then you start to refactor or to split info small services, this task should be proceed as other branch while operating the existing system which is migrated to container ways.
Rather more important thing is migration of your application or service to container manner. You can get the benefit of automation as of that time.
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.
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 8 years ago.
Improve this question
We are building a new app that would require to store some data in S3 or DynamoDB. The number of users for this app would be relatively small (~ 500).
There are 2 ways of designing this.
We can either use the AWS SDK to persist information directly from the app
Build a back-end web service that talks to the data store and use HTTP to communicating with this service.
There are multiple pros and cons for each like Option #1 is way simpler and avoids a lot of overhead, Option #2 however is cleaner and provides better encapsulation. Also the back end web service could be used for any other task processing in the future.
Based on what aspects should once decide which option to choose ? Any help would be appreciated
I'm not convinced that the overhead of Option 2 is worth it, so I would go with Option 1.
Keep in mind that Amazon S3 and DynamoDB are Web services (as explained here for DynamoDB, same is true for S3). It's not like you're talking directly to a database through some specific port.
I would only go with Option 2 if I need to do server-side processing. If it's just for storing data, I would start with Option 1. You can always add the back-end service later.
Option 2 all the way forward, but give that back end service some role in your domain. Think SOA.
If you are talking only of "storing" in Dynamo, even option 1 will do. (Be aware that you need to keep the AWS secret and key in the app).
If you also need to "read" then option 2 is better, since you will get the flexibility of keeping a cache (like elastic cache) between your backend and dynamo to increase response times. Dynamo is "single region". Unless your read happens from the same region, then it is going to be very slow - latency issues. And this cache will help you reduce the cost of the dynamo, since you dont need to increase the throughput so high - Nothing is as fast as an in-memory cache !
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.