Closed jimmidyson closed 7 years ago
Absolutely true. I even wonder whether API is relevant as its a technical detail, too (and an API per se is nothing 'executabl'). Maybe ipaas-server
or ipaas-gateway
would be more appropriate ?
Or ipaas-service
?
How about ipaaa-rest (might have ipaas-graphql in future perhaps) & ipaas-web (don't really like ipaas-client either tbh)?
Whatever is decided, I think it would make sense for us to be consistent, as you pointed out @jimmidyson :
ipaas-frontend
& ipaas-backend
, and anything else would have to be specified (e.g. ipaas-graphql
, ipaas-data
, ipaas-data-mapping
, ipaas-mapping
)ipaas-java
& ipaas-typescript
or ipaas-angular
ipaas-api
or ipaas-rest
& ipaas-ui
ipaas-server
& ipaas-browser
I don't think client
or service
should be used for either, imo, as I think they are loaded terms that can apply to both, depending, or multiple things (even server
, application
, or web
for that matter, depending, but I think we could get away with those more easily than with the other two).
I like the first suggestion with ipaas-frontend
and ipaas-backend
as it points out the architectural roles of these components.
Since we are in the redhat-ipaas
organization anyway, why not simply call it frontend
and backend
leading to redhat-ipaas/frontend
and redhat-ipaas/backend
? Of course, if the project names should stand for them alone, then an ipaas-
prefix makes more sense.
This could also have the advantage that for submodules we could use frontend-
and backend-
as prefixes without making the repo names too long (e.g frontend-datamapper
instead of a ipaas-frotend-datamapper
). Of course we could also use shortcuts like fe
and be
(e.g. ipaas-fe-datamapper
or ipaas-be-connector
).
At least we should stay consistent (which e.g isn't the case for fabric8 where we have the orgas like 'fabric8io', 'fabric8-quickstarts', 'fabric8io-images' ....)
We're likely to have multiple "frontends" in future, e.g. admin frontend. Same for backend.
My choice is ipaas-rest
& ipaas-ui
. I do like having ipaas-
prefix in the repo name. It's annoying to have to change the name of the directory when you clone IMO but that's personal. If you feel strongly about it otherwise, let me know.
No, no strong feelings about this, ipaas-rest
and ipaas-ui
is fine for me.
@rhuss , At first glance I also prefer ipaas-backend
and ipaas-frontend
, but @jimmidyson is right; in the long term there will likely be multiple frontends. You could say the same for ui
though, couldn't you? In which case I think maybe ipaas-rest
and ipaas-web
or ipaas-browser
(as much as I hate the name) would make more sense? What do you guys think? If the frontends would be iOS or Android apps then we could obviously just use ipaas-ios
or ipaas-android
, respectively.
Also @rhuss , my first instinct was to omit the ipaas-
prefix, but when discussed with @gashcrumb we came to the same conclusion as @jimmidyson and figured that it be best to include ipaas
for development purposes (when cloning, consistency when packaging and naming for NPM or Yarn, etc.).
I completely agree though that if we do have the prefix it should be consistent lol ;D. Whoever started getting creative with fabric8
and fabric8io
prefixes should be told to stand in the corner for 10 minutes, on timeout, to think about what they've done.
Who said naming is hard? :-b ipaas-rest
is decided now. ipaas-console
?
Can we keep it as ipaas-ui
? I hate the word console
, but that should not be reason enough to make any decisions. 😂
I like ipaas-rest
though! 👍
Renamed to ipaas-rest
& ipaas-ui
.
Anyone mind if we do that? The naming doesn't make sense anymore now this is the actual REST API for iPaaS, being Java is irrelevant.