search

Human-Connection / API

The API for a better world.
https://human-connection.org
MIT License
35 stars 16 forks source link

Maintenance: Reduce size of docker imge #168

Open roschaefer opened 6 years ago

roschaefer commented 6 years ago

Our current edge docker image is 205MB big. That's way too large. Probably there is some potential for minimization of the image size. https://hub.docker.com/r/humanconnection/api-feathers/tags/

realB12 commented 6 years ago

My opinion is - and I know, you don't even listen - following a distributed Microservice oriented Architecture would have been a much better approach... For instance I would make the database and API-Server two independent Containers that are both running as a) cloud instances every developer can access and b) local instances for developers working on a specific container (when you have to work on several container/services in parallel, there most probably is something wrong with your development process or role distribution in your team). But ok - I stop her - just giving this as a teaser what kind of discussion should be held here. Maybe you want to hear more. Or just forget about. I do not really care ..., I see you just running into issues, that might not have been an issue, when done differently right from the beginning.

roschaefer commented 6 years ago

Hey @realB12 why do you think we don't listen to you?

I opened this issue in our pair programming session today. We discovered that the file size of the image has significantly increased and we didn't notice. It's probably caused by the changes to the Dockerfile in #148. Do you want to help us optimize it?

roschaefer commented 6 years ago

Regarding your suggestion of a distributed Microservice oriented Architecture - feel free to open another issue and describe the architecture and the pros and cons. In that specific case it would be great if you could draw a diagram of the architecture to help us understand. See this example here.

E.g. at the moment I don't quite understand what you mean with "I would make the database and API-Server two independent Containers" because that's actually the case :thinking:

ghost commented 6 years ago

@realB12 I think you need to start at the very basics of feathersjs here: https://feathersjs.com/ as we already have a very granular micro service architecture setup, just not spread into different projects which isn't necessary as of today. However, if you feel that our current setup isn't working well you're invited to bring any pitfalls to our concerns (with proof of code/use or showcase please) and we'll discuss it. You're also much welcome to send us a draft as @roschaefer mentioned.

If you're new to nodejs, feathers and nuxt feel free to join our discord and we will help you to gather the required knowledge. If you already have some or more deep knowledge, even better! Just jump on the train, contribute code or ideas. For discussion on topic's please open a separate issue if there isn't one ongoing already.

We also do pairing sessions every now and then or on demand and a weekly or bi-weekly developer meeting in voice/video chat will follow soonish.

Thanks and have a nice day!

realB12 commented 6 years ago

I am talking concepts and logical architecture not physical machines or code. Providing similar diagrams or code will not improve your insight nor will it help to get my message through. This would be just more of the same stuff, that is keeping you trapped in the box. This is what I have meant - when telling you, that you are not listening. It's like I am telling you, that I would like to have two little, different cars rather than a single one and you are telling me, that I should provide a blueprint and a better/alternative description of what you already have. Anyway. I do not want to disturb you here. Maybe all this is not important in the current situation with the team still small and the future uncertain. So why planning big, when we are not even certain to survive the next months, right?

Concerning Feathers: I will have a look into it. However I keep saying to mayself - a fool with a tool is still a fool ;-) So USING Feathers alone will not do the trick. We have to use it the right way to build the right things that will work with professional top notch scaling hosting solutions. I am too far away to have an opinion here. But - we are using Feathers and everything is solved - for me, is not really a convincing argument ;-)

Lulalaby commented 6 years ago

Without getting too close, I think you're exaggerating. We listen to you, but we have our way, which works very well. I don't know you personally and so I can't tell if you're trolling or something. "a fool with a tool is still a fool" is already quite offensive against the developers here who put their life and lifeblood into it.

Please hold back a bit.

ghost commented 6 years ago

then tell me please how you want to contribute to our software? And why exactly do we need to listen to you? Who are you? Linus Torvalds? All you did as of now is making NS comments which have NO value, come onto discord, join the discussions on real problems, start contributing or roll your own, it's open source.

Oh and when you are done with feathers I hope you notice that almost every aspect can be put into a microservice. And even if it should be obvious let me enlight you: feathers is not a tool

Last time I clearly provide you with an anwser on this matter:

WE refers to the team including all contributors together, participation takes place on related github issues and on discord (you are free to say hi in discord since you're already on the server), join the discussions and help us get stuff done.

realB12 commented 6 years ago

No "WE" is the stuff you already have in place and the core team defending it as hell ;-) It is ok for me. I am out.

Lulalaby commented 6 years ago

I'll say it only once now: We (the team and several helpers) are all working hard on it. Do something besides commenting, complaining and spurring on or just leave us alone.