Nombre d'application(s) front-end

[nicolaspayot]

Une question soulevée par la PR de @mbaechler : est-il préférable de développer une application front par domaine / contexte ou une seule pour le projet meetup ?
Je dirais qu'une seule va dans le sens de la simplicité / maintenabilité / consistance. Plusieurs, cela permettrait d'utiliser différentes technos.

[jeantil]

I believe KISS in this context would be to create a unified frontend to start with unless there are too many frontend contributors for a single app in which case modules can be separated early.

The boundaries of the frontend module will most likely be imposed by the user experience design rather than by the arbitrary lines chosen to split the backend.

Ultimately modules can be extracted if it makes sense, if the design is good, extraction shouldn't be too hard. Also there could be a lesson to be learned by comparing approaches :YAGNI+monolith+refactoring vs early modularization

The domains identified during the event storming should still be respected though.

[nicolaspayot]

Looks very good to me.

[mbaechler]

👍

[devcrafting]

I also like this point of view.
The first sentence is important however, since we don't know how many contributors we will have and on which context.
For exemple, with the 3 contexts defined as of, I would say that Events and Subscriptions will have quickly some frontend in common. Can we really build a frontend for Subscriptions out of Events frontend ?
For Activities, I am wondering if an isolated frontend would be a better idea, to avoid useless monolith at first ? When we will talk about integrating Activities in Events, I agree that we will probably need to modify Events frontend.

Do you want to create a separate folder for frontend(s) ?

[nicolaspayot]

Yes, I think we could start with something like "WebApp" (or any other significant name) in the root directory. I'll bootstrap a React app within.

[devcrafting]

Ok then we should discuss (on Slack) about the process. I started working on Activities and I am not really fan of thinking only to backend or have to wait for React WebApp to be initialized/normalized (lots of discussion to come I imagine).
Behind this remark, there is the principle of separation : function team (i.e front/back) VS feature team (i.e events/activies...). I prefer the second...I fear to end in the first one, with all the drawbacks.

[devcrafting]

As discussed on Slack, we will split in 2 WebApps to avoid useless coupling betweeen Activites and Events contexts for now...then will see what's next.
Close issue ?

[jeantil]

ok with me

On Fri, Feb 12, 2016 at 9:32 AM Clément Bouillier notifications@github.com
wrote:

As discussed on Slack, we will split in 2 WebApps to avoid useless
coupling betweeen Activites and Events contexts for now...then will see
what's next.
Close issue ?

—
Reply to this email directly or view it on GitHub
#8 (comment).