Write reusable modules for common functionnality
bakura10 opened this issue · 12 comments
Hi,
Now that I4ve been using ZfrRest for production, I think we should stabilize the core. Once it's done, I'm thinking about writing reusable modules for common funcitonnality, like user. Those modules will be based on our experiences in ZfcUser, BaconUser, but targeted to ZfrRest and a 100% restful architecture.
Seems a good idea to you?
Looks good, but only if they are minimal/maintainable...
Yep, the idea is to give minimal modules. My thought is that ZF2 proves us it's nearly impossible to have completely generic modules if you don't make some assumptions about the underlying architecture, because trivial things like forms or input filter or services completely depends if you are using REST, not REST...
So the idea is small, specialized and extensible modules that iwll take ideas from eveyrhting we've learnt, but that will be thought to be workign with ZfrRest.
I want to have only things that are common across a large number of apps. Here are my ideas so far:
- ZfrRestUser: will steal a lot of ideas from BaconUser, but targeted to REST only.
- ZfrRestPayment: a lot of apps need to accept payments. I have worked on Stripe a lot lately, and it proves to be a very popular way to accept payment (and very simple to implement with REST). The idea is to have a backbone that you can use to accept payment using Stripe, and abstracting all the payment related entities, and creating some reusable services to create plans, customers, subscriptions...
What do you think?
Hi, what about a module for provide REST authentication ? It's on ZfrRestUser or it still better to create a specific module ?
Authentication for REST already exists: it's ZfrOAuth2ServerModule.
ZfrRestUser: will steal a lot of ideas from BaconUser, but targeted to REST only.
This is what I'm talking about - I'd personally avoid re-writing such things, and use third-party modules directly. A ZfrRest+BaconUser module would just be the glue in-between.
No, that's the whole point. Remember all the conceptual problem we had with BaconUser because of the forms things, having form in the service, or raw data in service.... It's honestly MUCH simpler to code it once and adapt it to the specific use case. Trying to adapt things that are "too generic" is a bad idea, tmh, especially for things that are actually business-specific things.
@bakura10 Yes I know ZfrOAuth2ServerModule, you talk me about it :p. I had not seen it was already managing the mapping with a user entity. My bad 👎
Trying to adapt things that are "too generic" is a bad idea, tmh, especially for things that are actually business-specific things.
Yeah, but authentication is not business-specific :P
Taht's what I wrote ZfrOAuth2Server :D.
Hi!
I'm going to start working on ZfrRestUser today ;). Tasks: do it as light and extensible as possible, thought for being used in REST context only with ZfrRest.
+1000