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.