After 2 years of working on java, spring framework and springboot, now I am trying to make my first website. It is just a 3 pages website. I use html, css and bootstrap on the frontend and springboot for backend. I have 3 questions:
for backend do I need a "service" class and "service" interface? on the top of "controler" and "main" classes?
where do I put the photos? I mean some people says put them in the database table, some other says DB becomes heavy when you want to load it.
I would like to use this website as my work sample, how can I host it for free in the cloud, I think I need to host my website in the cloud, correct me if I am wrong.
It depends on your needs. If the controllers' function is to return the frontend layer, then no. Generally, services are the spring way to connect the business logic layer with database layer. Which brings us to
the necessity, or its lack, of implementing a database at all. I'd say that if you have just a bunch of static images, feel free to place them somewhere in resources and don't bother with implementing a database layer at all. But if you, on the other hand, need to store an extensive amount of files and, more importantly, need to add and remove them dynamically, database is the way to go.
As for hosting: I have little experience with devops, but I'd just throw it out there, that AWS has its free-tier, lasting 12 months.
Related
There is a project that is built using JSF with Spring Integration.
See https://www.tutorialspoint.com/jsf/jsf_spring_integration.htm to get an idea.
JSP is used for the html templates. Managed beans (part of JSF) make use of Spring beans as a managed property, which in turn drive business logic. The goal is to rip apart this project and split it into a RESTful service and Angular front end.
What is the best way to do this without re-writing everything. Which components can I get rid of, and which components can be re-used? If I use Spring Boot for building the REST API, can I re-use the Spring beans?
Edit: I am new to most of these technologies.
Exposing your domain model through REST should be relatively straight forward using Spring/JPA, whatever. You should learn about DTOs and especially as it relates to problems about "Lazy Initialization" under Hibernate/JPA/Spring Data, etc.
Secondarily understand the concept of views into the domain model. E.g., shipping looks at the database differently than marketing. Same database, different "facades" or business layers with different set of DTOs.
Conceptually, reproducing a JSF front end in Angular is something that is both "the same thing" and "completely different" at the same time. The key difference, IMHO, will be the JavaScript concepts and paradigms underlying Angular/React/Vue or whatever you want to use on the Front End.
Consider that an AngularJS/React/Vue front end might be better off running on top of node.js in a separate container or server, and might have different databases that it accesses on its own such as loyalty points or currency conversion, etc. Don't be afraid to let the frontend folks "be" the application instead of the backend folks. On the backend, try not to lose information. For example, if a customer adds 3 items, then changes 1, then places the order, that's 3 separate pieces of information, not 1 order. This is important for business analytics and customer service, which are business facing services as opposed to client facing services.
As a Java developer I tend to feel Angular/JS developers do a completely different and non-overlapping job than me. I feel the same way towards HTML/CSS folks. As such, I don't recommend you try being both, you will stretch yourself too thin. However, a good working knowledge on a smaller project, such as you are suggesting, is certainly useful.
Welcome to SO. Your post will probably be closed/ignored for being to broad, etc. Very specific questions and answers are what this site is about. GL.
I am trying to integrate spring-mvc and reactjs, but it's too poor example, but I like flux architect of reactjs so that i strongly want to integrate reactjs with springmvc!
I want to use reactjs as a client side, springmvc as a rest backend. Can you provide me some example or tutorial to do this? I've searched on google but it's very poor result. Please help me.
Thanks you very much
This answer might not be what you want, but I would advise you not to integrate the two of them. If they communicate over HTTP/WebSockets, they are already decoupled, and it might just cause you pain to couple them.
Advantages of decoupling the frontend and backend into separate projects:
People with experience only in React or Spring can contribute without getting confused by the other stuff.
The tooling/build you need for a Spring project is quite different from what you need for a frontend project, and mixing this into one code base can get pretty confusing.
If they're decoupled from the start, it gets easier to add other clients that use the backend API. By having them as separate projects, you're less likely to develop the backend in a way that's very tied to the frontend.
The frontend and the backend should use different versions and be shippable independently of each other. What if the backend team is currently doing a major refactoring, but the frontend team just fixed a critical bug and wants to ship a new release?
As soon as you add asset caching to your frontend project (like putting the files on a CDN, using the HTML5 application cache or the new Service Worker API), you have to prepared for getting requests to your backend from "old" clients. By separating them, it's easier to think about and plan for stuff like that on the backend.
I could probably list a couple of more benefits, but these are the ones I consider has the largest impact. There are of course some benefits of integrating the two of them, but those tend to get smaller and smaller as the project grows/matures.
We are about to embark on a new project development which is basically a Back-office application.
We chose the following technologies in our backend:
Spring, JPA, mySQL , MongoDB, RabbitMQ..
We chose to use GWT as our frontend framework.
My question is very simple:
Should we create one project, that comprises both the backend and frontend?
OR:
Should we create 2 separate project, one will be a pure backend project while the other pure frontend?
EDIT - we are a team of 4 developers each should get his hands dirty in an end-to-end development. i.e everyone in the team should code features from client to server.
It depends on different parameters, like final size of the project, number of team members, etc.
But in general I'd rather split projects in maven modules, because it allows a better client/server sides separation, it facilitates testing, and it's more convenient when you have people in the project focused in one side.
If you go ahead with this setup, I suggest to take a look to Tomas Broyer's archetypes
[EDITED]
Knowing that you are a team of 4 people and you are going to work for 8 months, I definitively will go with a multi-module maven project (server, shared, client).
For simplicity's sake, I would break it up in a pure frontend project and a pure backend project. The workload will be slightly more since you have to write a messaging service inbetween, but longterm, you can reuse that backend for other frontends / services.
Since you're going to use RabbitMQ for messaging, you might as well have them separate and when the load gets heavy, you just plug in another frontend instance or when the backend starts to suffer, startup another backend or when the queue suffers, startup another instance of RabbitMQ.
For the frontend project I would use something like XMLRPC, your GWT code will then communicate via XMLRPC with your Java code and voila, you can test the endpoints right there, develop by just plugging in dummy data right there and work on the frontend even without the presence of a database or queue system. This also allows you to start both projects at the same time.
So basically from a point of plug-ability and ease of testing and since you're planning to use RabbitMQ, two separate projects, if there was only one project containing both the frontend and the backend, then there would be no/little need for RabbitMQ and for every frontend you're starting up, you'd be starting up another backend which might be a waste of memory.
I am a beginner in magento and am working on creating a website using magento. I have noticed that magento has a good number of apis that expose all of the functionality that I would need to create an ecommerce website. So, I would like to use magento's apis to fetch data, but develop the UI separately without any dependencies on magento. I have found a lot of references that develop the website via magento theming, but not those where the UI is developed in a separate MVC and uses magento purely as service layer. Are there any problems/issues in my approach?
Edit: I have gained a lot of clarity on db performance issue in apis and how external caching can alleviate the issue, but I still don't understand the underwhelming use of magento as a service layer (i.e. fueling the website by using magento's apis), are they any other gotchas?
Here is how we overcame slowness in Magento APIs:
Created a Web service provider in J2EE, Spring MVC that acts as a proxy between Magento and end users.
J2EE Web service provider exposes pretty much all the APIs that Magento has but also supports JSON with REST along with SOAP & RPC.
J2EE Web service provider uses a document based database (MongoDB) to store a snapshot of product catalog in MongoDB.
J2EE Web service provider uses native MongoDB caching to serve data fast without running any expensive SQL queries.
To avoid dirty caching issues we created a hook in Magento Admin to push data into MongoDB whenever data changes in Magento.
This might sound like overkill to some but we have been able to achieve pretty high throughput without any slowness.
The Magento APIs are slow, you would encounter serious performance issues trying to run a site off of it.
Due to the complex nature of the EAV model, you may find it difficult to manage products through the API alone.
Are there any particular concerns you have about using Magento's own frontend? It is daunting at first but once you understand the layout system it's actually very powerful and customisable.
Technically it is possible to run a site only through the API.
The issue you might face is a practical one, instead of spending your time trying to learn all the API calls, you can learn how to implement your current UI in Magento.
The advantage to this approach is that you will also better understand how Magento works internally, thus allowing you to leverage it's functionality for your unique business needs.
Another issue is that when using API's you have a little less control over how things are processed / calculated, vs when working in Magento itself there is a lot of control over specifics.
I regularly see "session expiration" issues when accessing Magento's API, through both SOAP and XMLRPC. All my calls require exception handling to avoid halting execution. I imagine that alone would create a nightmare when building everything on top of the API.
The best answer you're going to get is to Load Test the API before you start coding. Log the tests extensively and look for errors. If you see errors on a normal basis that should answer your question. Even if you find documentation that says it's okay to do what you're trying, you're still going to have to tune the API to work properly under the load required to run the store.
It will be good to know what you're up against before sinking hours into development.
To start with, please be sorry, I just start developping applications on AWS and I have some question that could be easy for you but not really for me... But impossible to find any response about web integration of a java website on SWF...
I'm also a new user of the spring framework, I need to do some tutorials about it (or not? SWF documentation can be enough?). But my questions are for those who have already passed time on it and can say what is the best aproach in my case. (And why?)
What is the good approach in UI design to have a web based application with ui dynamic changes? (like content slide, menu, etc... the most scalable choice)
Having the view (GWT web interface running on Elastic Beanstalk for example, or a CloudFront PHP interface using a good MVC PHP Framework?) separated from the model running on SWF? All linked by the API's.
Or having my complete web application using Flow FrameWork and GWT? (or another technology? For now I chosed this even if I have to work tutorials too, but why not using the new Dart Google's solution?)
What is the easiest approach to do it efficiently?
I understood the SWF logical approach, and I have all my project's architecture (so the scalable SWF Model) in my head, but clearly, if I want to add a new service in my project and if this service wants to get a list of existing objects (stocked in DynamoDB for example), i'd like to show this information easily because I already did it for this object.
And so, with a copy of the model on the PHP interface, I imagine I could associate methods to show this object, and so concentrate the PHP projet for showing my objects and start workflows with PHP (search and read-only?), and SWF to have a good working model launching those WF. Is it a good approach? Is there a PHP framework really adapted to do this? Rather, I do it on a non-swf java UI application?
Finally I found what I was searching about. To connect an UI interface, we have just to use good classes of the SDKs :
http://docs.amazonwebservices.com/AWSSDKforPHP/latest/index.html#i=AmazonSWF
http://docs.amazonwebservices.com/AWSJavaSDK/latest/javadoc/index.html
My question was really simple, but I wasn't able to understand the entire SWF architecture.
So the solution is to implement the application's MODEL-CONTROLER with the SWF Flow FrameWork, and after that, we can connect the VIEWs with any of the SDK to start workflows. We can also connect an Android or iPhone application easily with the good SDK.