Gorigori SIer SE created a web service by personal development It's like the continuation of.
Last time I wrote a story about "I tried to make a Web service". Looking at the one I wrote, I thought, but most of the introductions of Web services do not include much SIer elements. As for the previous intention, rather than appealing the Web service itself, I sometimes hear a voice saying "SIer just throws it to BP and does not program", so SE who has only SIer experience is programming and it is like a Web service I wanted to show you one experimental result that it would look like this when you make it.
Set aside whether it was a success or a failure.
However, I feel that I only wrote "I made this", so I will roughly describe the process of development, so I hope it will be helpful.
It's really rough. Not modern. It feels like a reading material. It is a "poem" tag.
This time, "what I want to make" was the catalyst for my development. It is good to systematically learn from scratch by tracing, but what are the functions required for "what you want to make" and the technology required for those functions? As I proceeded while thinking about it, I forgot the time and it became more and more shaped. However, I don't think "what I want to make" comes out so easily, so I think it's good to just ask various people "what they want". If you make it "what you want to make", I think that your hands will move freely.
With that in mind, what should we start with ... I imagined a production environment. I have no modern experience. "Well, it's the first personal development, is it okay to have one server? So, Apache Tomcat for the Web / AP server and MySQL for the DB, but this time MariaDB who has never touched it!" Like. The rest is the language. As I wrote before, I chose Vue for the front and Java (Spring Boot) for the back end with the intention of learning a good balance between inexperienced Vue and experienced Java. And an editor. I have experience in C # and Java, and I have used it in business with Visual Studio and Eclipse. I don't have a license for Visual Studio. In my experience, I'm worried that Eclipse is heavy and sometimes moss at startup. I chose VS Code because VS Code, which I often see, is light and seems to be easy to use for Java. There is no particular source version control. There is no such thing as a container.
First, I started making it from the login screen. First of all, the login screen ... isn't very interesting. I implemented it using the function of Spring Boot.
Next, the basics of SIer, the master maintenance screen. The image that the mass men screen is first created for SIer to learn development. Since I have experience, implementation is completed for the time being. At this time, I haven't decorated anything yet. I showed Yome the login screen and the mass-men screen, saying, "I was able to do this." The reaction was something like "How many hours do you spend like this?" It seems that the impact of the appearance was stronger than how the function was. This lowered my motivation. So at this point I introduced Vue,
I'm an inexperienced Vue person. (I handle plain JavaScript as it is) It's a library, and you put the file somewhere and refer to it? This is what I thought. If it is for learning, it may be like that, but when I installed Node.js and Vue CLI and created a project from Vue CLI, something different from my imagination came out. Feeling to move alone ... My Vue level.
In my work, I write specifications, have them review them, fix them, and review them again ... but this time I haven't done that in detail. As an SIer, I have experienced everything from "requirements definition-> external design-> internal design-> implementation-> various tests-> release", so I may have done various things in my head. The flow this time is for each function ・ Memo of screen image ・ Memo of screen transition diagram ・ DB table design memo I made it. And they aren't at hand right now. It's lost. When taking over the business, it is necessary to say "There is no specification. Please see the source." Even if the screen image or screen transition changed, it was closed within the function, so the effect was small, but when the table item changed, the effect on other functions was large and it was a lot of trouble, so I thought about it a little more properly. I should have done it ... now I think.
Now, we have two execution environments, Node.js and Tomcat. Nowadays, the image of converting the backend into a REST API has been solidified. At the time of development, I put the Vue project into the Java project and launched both Node.js and Tomcat. In the production environment, I made the built Vue file included in the war file and put it all on Tomcat.
Recreate the login screen and mass men screen with Vue + Spring Boot (REST API). When I searched around here, there were various ways to do it, so I didn't get stuck there.
I used Element for validation at first, but when I tried to handle server-side errors, it didn't work, so I switched to Vee Validate. I'm doing something with Vee Validate.
The implementation flow was generally routine. Screen creation (Vue) → Table creation (DB) → Repository class creation (Java) → Service class creation (Java) → Controller class creation (Java) → REST API access part creation (Vue) → Screen adjustment (Vue) It feels like repeating this for each function.
By the way, in my experience as an SIer, I have only worked with designers for a while, and I have little knowledge of design. So the design is indescribable.
The creation of each function was based on experience and services that are full of the world. Exclusive control was done finely ... Also, there were many sites that taught me how to implement chat, etc., without having to refer to the services that are overflowing in the world. However, since there are many simple chats, I thought about whether the members were online, the delete function, and the display of icons.
When I tried to implement the function to delete the chat message later, it turned out that it could not be deleted due to the structure of the table. At that point, I reviewed the structure of the chat table quite a bit, so the range of influence was great. I thought it would be okay to delete the message later, but I also thought that the structure of the table should have been taken into consideration to some extent.
I showed it to Yome often, but he said something quite harsh. Especially the design and operability. Do you say that much? About. Well, that's what's important to users. I am grateful that there are some parts that have improved while being damaged by pointing out that there is no body or lid of Yome.
During development, he comes from time to time. "Who will use this service ...?" It becomes a big shadow and wraps the view in darkness. Review "It's a fucking service" Review "cannot be used" Review "too many bugs" Negative evaluations run around in my head. And I want to stop and throw everything away. The unfinished apps that were stopped and left unattended in that way will be sleeping everywhere.
In such a case, it may be necessary to regain the reward from the user's point of view, but I escaped to the fun of programming. Then, when I feel calm, I will return to the user's perspective. I managed to keep my motivation by repeating it.
I thought that I would like to add a function to synchronize the screens of users with WebSocket like chat to task management, so I thought to realize it with Vue.Draggable + WebSocket, but one subtle, no, quite worrisome Phenomenon has occurred.
Symptomatic treatment of Vue.Draggable's strange movement
The movement is subtle. After all, I was worried about two days and managed to get symptomatic treatment.
The server used AWS EC2. At first, I used an instance of the free tier, but since the memory was too small and it affected the performance, I made it a little better spec even if it was paid. Study fee, study fee ... Just set up the DB and Web / AP server here and put the built module on it.
After creating all the functions, I started to acquire the domain required for publishing and to make it HTTPS. I was wondering if something would be difficult, but the domain acquisition and HTTPS conversion were completed easily on AWS. It seems that the .com domain costs about 1,000 yen a year ... We prioritized convenience over free.
When you're ready, just let us know. This time I announced it on the SNS where I have an account. When I pressed this button, I was notified ... I was in a state of finger pulling.
There is not much difference. Sometimes I get a bitter comment and sink ... I think it's quite difficult to get them to use it. I haven't decided what to do in the future. I think it's most important after it's released.
I'll develop it! It's roughly like this from the decision to release. There are few technical elements, but it's a poem. What I thought about it was that even if I thought, "Oh, this is definitely not going to be solved!", It will be managed within a week at the longest. It will be solved unexpectedly. It's solid, but I can think of it in the bath or toilet.
When I do that, the question "Who will use this kind of service ...?" Always comes up. I don't think anyone actually uses it. But I think it's important to experience it until it's released once. If it doesn't work, you can just make it again. I'm not a strong mental person with a bristle heart, but I'm dented but willing to move forward. So even if you have never made a public app, why not try it?