You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 27, 2019. It is now read-only.
Repository navigation
This repository was archived by the owner on Jun 27, 2019. It is now read-only.
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.
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?
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 🤔
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 ;-)
Reacted by Lala Sabathil, Grzegorz Leoniec and Robert Schäfer
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.
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.
Activity
realB12 commentedon Sep 22, 2018
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 commentedon Sep 23, 2018
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
Dockerfilein #148. Do you want to help us optimize it?roschaefer commentedon Sep 23, 2018
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 🤔
realB12 commentedon Sep 23, 2018
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 commentedon Sep 23, 2018
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.
realB12 commentedon Sep 24, 2018
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 commentedon Sep 24, 2018
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.