Static food data new structure
This article is part of our plans, related to groceristar-fetch, aka static food data plugin.
In order to not get confused, please read the
- introduction(https://medium.com/groceristar/groceristar-fetch-small-module-that-weve-created-8b4a62bd5d7b)
- the first part(https://medium.com/groceristar/food-static-data-plugin-list-of-big-steps-66265919df0f)
- second part(https://medium.com/groceristar/static-food-data-plugin-transition-to-es6-559d0d941ec6)
The big part of our next version related to code structure. As a project manager, it’s not easy for me to think about it. The biggest issue is to update it quickly or make a few iterations, in order to make it work for all cases.
If we’ll put our focus on releasing big major update(aka release 2) — we’ll crash all of the small projects that we’re working on.
If it wouldn’t crash anything — then we’re doing bad :( But I think we can find a way — that will prevent everything went down. But it’s not a simple thing.
Basic work should be related to:
1) Reduce the number of methods, and remove methods with similar logic.
2) I think we need to move away from our basic methods
4) Move away default getters
3) Find a more simple way of getting data and change the data structure. For 80% of cases, we just grab
My goal was just to keep all static files/data in the same separated place from the beginning.
So we didn’t keep a lot of attention to what structure we have. Right now we have 2 main folders: `data`, `projects`.
- Data — just have all of our files/tables/structures at separated folders.
- Projects — have sub-folders, each sub-folder related to a separated project, where we’re using our data and methods, that help us to manipulate our data as we need.
Keeping different projects in one place is a problem. And actually a number of projects/branches is growing, and we adding new methods each week. Everything starts to look overcomplicated.
Files and json structures have a legacy of my first Loopback servers(each of these servers are holding us back). And some code that we have are 1.5 years old and a lot of things has changed from that time.
Maybe we should use an approach, that is similar to learna (https://lernajs.io/)...
Basically, what it means that we have a package(repository), that have sub-packages, that can be our projects. Each subpackage is also a module.
It can have separated version control and stuff, but without npm publish feature. It’ll require the implementation of real development work styles. Without a proper git-flow, clear tasks explanation, extended number of contributors, task maintainers and clear goal setting it will be hard to do/manage/implement. Because it will be just another thing that I should keep eye on it.
it’s also hard to keep everything in one GitHub repo and maintain issues and explanation sane and up-to-date. Right now the half of tasks are in-process, half should be finished in order to move changes into all of our projects, etc. Same stuff with testing tasks, that we trying to complete about a half of the year.
Separation of static files will help us to make it easy for applying at other coding languages, not JS only. Maybe one of our previous repositories should have JS support, but when it builds — it’s just a clean plain JSON without anything. Maybe it makes sense but it should be tested, before making any choices.
If we have a separate npm package for JSON files and keep our methods at current package — it will make our repository less confusing. It gives us the ability to split the development process in a few ways.
Some of our data is not related to food. it just structures, related to our DB tables. And we have them as files. Instead of having files we need to use methods, that will pack that data and save that stuff at files.
Another problem — different projects can have a similar logic but with different table structures. it’s hard to have them at one place, be aware of these files and understand why we have files with similar schemes(as recipes, ingredients) but with different structures inside.
