Feature roadmap 2022 #1077
Replies: 8 comments 9 replies
-
|
I would like to introduce platform agnosticism at some point. That way medusa could provide the AbstractHttpServer while a package for each platform could exists. Platform-express, platform-fastify, etc… all the plugins would be then based not on express typings but on medusa abstraction. I could when time is there add the abstraction and the express package to medusa. Then I could provide myself the package for fastify and anybody would be able to add any platform of there choice. why, because it will first allow to use platform with better performance like fastify (x2 min) and also help integrate people from other platform without locking them up with express. what do you think? |
Beta Was this translation helpful? Give feedback.
-
|
That's nice, I would love use another authenticator service like Ory(kratos,Hydra), Auth0, AWS conignto, ... |
Beta Was this translation helpful? Give feedback.
-
|
hey @olivermrbl . Can you explain why multi-warehouse is on hold, and in case you already started working on it, would be possible to contribute to it? |
Beta Was this translation helpful? Give feedback.
-
|
Would like to know aswell. Pretty important feature in my case. |
Beta Was this translation helpful? Give feedback.
-
|
@johnyvelho @HarunKilic We expect to initiate the work on multi-warehouse support in Q4 this year. We'll post an RFC in here very soon. If something changes I'll make sure to keep you posted 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the update! 😊 |
Beta Was this translation helpful? Give feedback.
-
|
If medusa can be integrated with Hasura, all features included in the H2 and a lot more can be done easily moving foward with Hasura graphQL advanced queries, mutations, subscriptions, custom fields, events driven actions, REST connectors, RBAC and third party integrations... like Strapi for CMS, etc. I would love use another authenticator service like Ory(kratos,Hydra), Auth0, GoTrue, AWS conignto, ... All the store core logic will be keeped inside Medusa while Hasura will the heart in the system... Very strong stack! |
Beta Was this translation helpful? Give feedback.
-
|
How come you decided to discard GraphQL? I know a few agencies have been waiting for it.. |
Beta Was this translation helpful? Give feedback.
-
|
Appreciate the interest. I've answered your question below. |
Beta Was this translation helpful? Give feedback.
-
|
is there any update on GraphQL support? |
Beta Was this translation helpful? Give feedback.
-
|
Appreciate the interest. I've answered your question below. |
Beta Was this translation helpful? Give feedback.
-
|
I think one thing that will be important for the Tax API, if it is not already there, is that tax rates can be applied with an effective date, much like price lists. As of x date, these are the tax rates for a tax category, etc. I don't think the current product includes that capability. @olivermrbl |
Beta Was this translation helpful? Give feedback.
-
|
That is an interesting suggestion @fosrias, and would definitely improve the merchant experience. Though, I would argue that you typically have significantly fewer tax rates to manage than prices in a price list, and manually updating these seems much less of a hassle. I am curious to hear more about your use case to see if it would make sense to make this a priority in the near future. |
Beta Was this translation helpful? Give feedback.
-
|
@olivermrbl The scenario, and I actually think this is a global problem on numeric change that affects order calculations (prices, tax, codes, even reassigning tax categories), is that unless you have an effective date, either you have to have someone make the change on 01/01/xxxx at midnight manually type of thing, which may be on a weekend, or you end up having incorrect orders in your system that you have to correct some other way manually as well because the taxes were not correctly calculatred. What I am pointing out is to have an effective date where you can actually manage when changes affecting orders get applied at your convenience. Absent that you have have scenarios that manually changing is less than ideal, even if it is lower volume changes. My comment on using lists is less about volume, but more the experience of how I potentially change a bunch of tax categories or tax rates with an effective date at the same time. That is less important than being able to just have an effective date on the changes, which could just be done one off with every individual change, but I suspect that may get onerous quickly and thus the comment on something like price lists that can more broadly apply the changes all at once and then be picked up when they effective. Again, I think this goes for any change that will effect orders calculations so that you can configure them at your convenience and they go into effect on the specified dates. Does that clarify? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks - appreciate the level of detail. It makes a lot of sense. Having this flexibility around the concepts influential to the total order amount/calculation is indeed important; I just had not thought of it in the context of tax rates. I imagine this would be supported similarly to how price lists are built - much like you mention. Effectively, we would allow merchants to create a "Tax definition" (for lack of a better term) comprised of tax rates, categories, effective dates, and possibly more. I will highlight this during our next backlog review and get back to you with an update. Again, thanks for sharing. It is super valuable. If you find other areas of improvement in our feature offering, please don't hesitate to share - obv. you have better things to do, but we'd love the feedback if you can find the time. |
Beta Was this translation helpful? Give feedback.
-
|
@cbsummerbird @anle1991 GraphQL API is on hold for now, as we have other features and improvements we deem to have higher priority. We generally approve of the idea behind GraphQL and believe it can contribute to an improved developer experience, but the implementation comes with its caveats. It requires us to re-architect our API layer, maintain two types of APIs (REST + GraphQL), dedicate time (entire eng. organization) to master the domain, create entirely new documentation, and more. Our core commerce team is still fairly small and comprises only seven engineers. We simply can't justify prioritizing this over features and improvements that are must-haves and create immediate value for our users. For now, we've focused on delivering a well-defined and sophisticated Rest API that is easy to work with. That being said, we haven't removed it entirely from our backlog, and I imagine we will revisit the feature in the future when time and resources allow for it. |
Beta Was this translation helpful? Give feedback.
-
|
Is it possible to have someone from your team to take initiative on the project then extend support gradually? I think a good direction will also allow the community to contribute in a confidence way to the project if anything needed badly. I do agree it's not just a feature but a fundamental change because of that we need to kick it off sooner as Medusa gets more complicated, it will be even harder to achieve later on. |
Beta Was this translation helpful? Give feedback.
-
Write-ups for all features will be made available prior to starting the implementation process.
H1
Tax API
The new Tax API will enable the ability to have more granular control over taxes on different products and shipping options, across regions. Furthermore, the API will introduce support for using 3rd party tax tools like Avalara and TaxJar to handle rooftop specific taxes in regions like the US, but also to support things like duty estimation and tax liability control.
Admin Redesign and clean up
The admin redesign will bring a new look and feel to the admin dashboard. The flows and features available in admin will mostly remain the same, but will be more thoroughly tested with improved control and trust.
Promotions API
The current promotions module allows discount codes for free shipping, fixed amounts and percentage amounts, furthermore, there is the option of controlling scheduling and product availability. The new Promotions API will increase the control available to the store operator and will also introduce the notion of customer roles that can be assigned to customers and used in promotions.
Bulk Import/Export
The new import/export feature will make it easier to make bulk updates to products and will make it possible to generate export files for different entities in Medusa such as Products, Orders, Customers and Gift Cards.
Introducing strategies
The new strategy pattern will allow developers to override core logic in Medusa in cases where such overrides are necessary. For example, if a merchant wants to apply custom logic when generating line items in a cart; a strategy can be overridden to accommodate this. We will be introducing strategies throughout the core where opinionated implementations have been made. The current implementation will be moved into the default strategy, but now you will have the option of modifying the behaviour if necessary.
H2
GraphQL API (discarded)
To enhance the developer experience we will add GraphQL support for the API. To begin with we will only add GraphQL for fetches, but the plan is to support mutations down the line.
Extend Order API
Adds support for editing placed orders
Sales Channel API
Sales Channels will introduce a taxonomic level for store settings, allowing merchants to differentiate the shopping experience across multiple channels. This can, for example, be used to change product availability and pricing between different channels.
Multi-warehouse Support
Multi-warehouse support will allow adding multiple stock-keeping locations to a Medusa instance. Furthermore, settings will be added to specify how stock should be depleted across regions, channels, etc.
Extend Product API (TBD)
Adds support for features like:
Beta Was this translation helpful? Give feedback.
All reactions