Problems in creating applications
In a real project, what problems might we encounter when creating a new application?
- The process of creating an app is tedious, and a lot of things are similar, but you just have to rewrite them all over again. Some might say that Using Spring Initializr is fine for your own testing, but it’s still not convenient for real projects. First of all, each company should have a corresponding application layer specification, in this case a project involves multiple modules, from this point, Spring Initializr does not support; And then some of the company’s own two package, also can’t quickly reference
- Module problem: For some complex business systems, there are really a lot of modules. If we have not systematically studied relevant content or experienced such complex business development, it may be difficult for us to understand why there are so many modules. But there’s no denying that many projects are just that complicated
- Dependency issues: one is all kinds of open source dependencies; There are also some common components developed by the company itself, or components redeveloped based on some open source components. When referencing open source components, you usually refer to the corresponding official documentation, and the company’s own development usually has the corresponding access documentation. But if too many dependencies are involved, the cost of access can be significant. One is versioning between dependencies; One is the initial configuration of individual components. For the old students, it is relatively easy to solve, they have stepped on all the pits, but for the new students, it is a very painful thing: they may encounter various problems in the process, which will waste a lot of time. Environmental problems are very complicated
- Configuration issues: Each company’s management of configuration is certainly different, which is actually a headache; Detailed documentation is good, if the documentation is not detailed, very abrasive. There’s a missing configuration here to import this namespace, there’s a missing configuration there to import that namespace, where does the new guy know so much? Or how do you know that? This is when you rely on documentation, and I want to ask you, are you satisfied with the documentation you maintain? An application can rely on many technology stacks, and the documentation for each stack is scattered in different places, making it difficult to understand
- For some open source scaffolding projects on the market, they usually integrate a lot of features and are not very useful. What good is it if it doesn’t fit into the company’s own technology stack? Some apps simply don’t use that many features, and you have to remove them yourself and fiddle with them, which is more likely to cause problems
How to solve these problems
- The process of creating an application is tedious, with lots of similar things to write each time: we can provide templates, and then have a scaffolding to quickly create an application based on those templates
- Module issues: Scaffolding must support multiple modules, either based on Spring Initializr or implemented by itself, but it must support multiple modules
- Dependency problem: Generally, the company maintains a parent POM, and then all applications use this parent POM, which can effectively solve the dependency conflict problem
- Configuration issues: Scaffold-based applications that generate initialization code for imported components can be linked to documentation in code comments
What else can be optimized
- It must be simple to use: check the box directly on the interface, just like Spring Initializr and Ali Starter
- Flexibility: Dynamically adding and modifying component-related information, such as version updates, should be configurable. This part of the content can be maintained by the administrator
- Friendly tip: when the component is displayed, the corresponding owner and documentation link of the component should be displayed so that users can easily understand the component
- Sample code: When you create an application based on scaffolding, you can also generate sample code based on the component selected by the user. However, this section should be optional. Newcomers may have sample code that is friendly, but older students may not find it necessary
- Dynamic templates: Different business teams may need to generate different template code. How do you say? The hierarchy of applications is generally the same across the company, but different business teams may need to generate different templates, and without template generation there is a lot of repetitive work. This one also needs support
- Integration: if a new application is created within the company, it should be registered on the corresponding system. You can get through with the registration system. If the application is successfully registered, it directly jumps to the corresponding scaffold to create the application interface, and directly initializes the gITLab for this part of the file
How to implement
- I initially looked at the Spring Initializr implementation and thought it was a bit complicated and not flexible enough, so I implemented one based on Freemarker. A Freemarker-based implementation has one advantage: flexibility and high playability, for example: I want to add the corresponding creator to the code comment when I create the application. Is this a common requirement? The scaffolding connects to the SOS to retrieve the current app creator information, and when the user creates the app, we can store the corresponding user information in the context and pass it through to Freemarker. Similarly, based on this feature, we can define some other variables that are more playable
- Applications -> Modules -> Dependencies: Three layers. Dependencies are the specific dependencies in our application; Modules are generic: WEB layer, SERVER layer, CORE layer, etc. An application corresponds to one or more modules, representing the structure of the application. Based on this we can define some generic applications, such as simple applications, complex applications, test specific, and so on. In this way, users can quickly select a module to create an application based on service complexity. Applications, modules, and dependencies are configurable so that we can quickly create a new application template
- Template file: configurable. The corresponding template file can be uploaded from the console, but each template file should have a corresponding scope: all scopes, or for an application type, or for a module, or for a dependency
- Dependency issues: reference issues between dependencies, some dependencies may need to introduce some other dependencies in addition to themselves; One module can also be seen as a dependency on another, and these issues need to be addressed