This is the second day of my participation in the November Gwen Challenge. Check out the details: the last Gwen Challenge 2021
Previously, due to business needs, DART private warehouse (private server) was set up in the company, mainly storing and managing the components needed for flutter development in the company. Here we share the core process and technology with you. Please click “Like” if it is helpful
1. Why private server
Some students may ask, doesn’t DART officially provide a component warehouse? Why do you need your own private server? It feels thankless
In fact, dart private server exists for the same purpose as GITLab private server. Companies of a certain size will have some internal libraries/components, which may contain certain business components, and it is not convenient to directly push them to the public warehouse
On the other hand, if there are many business parties of FLUTTER inside the company and the upstream and downstream links are long, in fact, the open warehouse cannot meet the demands at all. Only through the customized warehouse can the existing platform and links of the company be connected more flexibly, and the expansibility is much stronger
2. Server solution
For this not rare appeal, we should first try to stand on the shoulders of giants and see if there is an open source solution to use, after all, it is already a big project to fully support all the commands of the regular pub:
Official pub warehouse address
Official private warehouse address
Byte open source private repository unpub address
Here the most complete should be the official pub repository code, but it needs Google Cloud service (AppEngine) to run demo (local can also be through the Development side of the document to get up, but my Windows OS has been running failure, various problems, give up – =)
Secondly, the official readme mentioned that if you just want to deploy a simple private server, you can try the second warehouse. Although this warehouse is currently in archived state, it still has the basic functions, the code is not complicated, and it is easy to run demo
Finally, I also found a byte open source private warehouse address. I feel that the official private warehouse has been added on the basis of Google service proxy, component verification, metadata database storage support (default support MongoDB) and other functions, demo is also very easy
Finally, after simple internal discussion, we still plan to develop based on the official private warehouse. Because there are few demands at present, the second one has been satisfied. After all, what is important at present is to quickly produce a prototype to verify the whole process
PS: I also found a component management scheme based on git system (such as using the company’s GitLab directly). I think it is ok in fact. If you are interested, you can try it yourself
3. Client solution
As long as the client is on the PC-Web side, it is usually used to log in to a website like pub.dev to publish, browse and download components
The open source solution here remains the same as the previous official and byte open source projects:
Official pub warehouse address
Byte open source private repository unpub address
In the official PUB, the code responsible for the client side is mainly concentrated in web_APP and web_CSS. Web_app is mainly responsible for the DOM structure and logic of the page, and web_CSS is related to CSS styles. The Web code here is basically realized by dart: HTML library. This is eventually converted to js code via dart2js and is not involved with flutter- SDK
The byte project has relatively little and simple client-side code, mainly in unpub_web, based on the Angluar-DART implementation (dart takes care of the logic that regular Angular JS takes care of).
Ultimately on the client side we decided to build from scratch based on the capabilities of Flutter for Web. Of course the overall page style and layout will refer to the website.
The main consideration is that this side is open to internal users, and there are many subsequent customization demands. In addition, the scope of reference for the above project is limited, whether it is the technology stack or the implementation, and it is also helpful for the subsequent research of FLUTTER for Web
4. Bypass Google login
In fact, we don’t have such a request here, because our subsequent component upload and management are going to be realized through the client’s own research, without the help of the pub command, but I also mention this common requirement here.
This is not required on the server side, the core logic is in the pub command line code, so the core is to change the pub command source code, remove or modify the authentication code (such as company email authentication), and then build a new pub command
There is already a detailed process of this aspect on the Internet, I will post a reference link, there is a need to have a look at the ha:
Blog.csdn.net/ameryzhu/ar…
5. Review
- Understand the need for dart private service
- Learn about existing solutions on both the server and client sides of dart Private Service
- Know how to get around the Pub command’s Google login requirements