Sharetribe Flex - Spill the beans!

Hi Team…very mysterious announcement of Sharetribe Flex…Can you provide any more insight! It looks like we are finally moving to a plugin framework. If the that is the case, will there also be a plugin marketplace?

1 Like

Hi Matthew,

Great questions! It’s still quite early days for Flex and many things are still under development, but I’m happy to share a few thoughts.

Indeed, the entire point behind Sharetribe Flex is to make it easy for anyone to extend their marketplace. This has been the single biggest source of feedback we’ve received: extending should be easier.

However, Sharetribe Flex has a bit different structure than Sharetribe Go. Flex is completely API-powered, so instead of extending the codebase of the backend that powers the Flex API directly, you will be able to simply write your own extension that has its own API, host it yourself, and have it talk to the Flex API. Once someone writes such an extension, it will be easy for anyone else to start using the same extension. We can definitely see there being a marketplace for these extensions eventually, but that probably won’t happen this year.

For those forum users who missed our announcement, here’s a link to the Flex landing page: https://www.sharetribe.com/flex/

Juho

1 Like

Sharetribe Flex looks very interesting, I was wondering what is the technology behind there.

So, inspecting sample Sharetribe Flex powered sites, frontend is a hosted custom ReactJS app, assembled and built from

  • Basic Application Template
  • Marketplace Settings
  • Custom React Components
  • Sharetribe JS SDK to talk to Flex API services

API services (most probably written in Clojure) at this time reveal to be very small, yet providing essential methods, like:

  • current_user (change_email, change_password, create, create_stripe_account, delete_stripe_account, send_verification_email, show, update_profile, update_stripe_account, verify_email)
  • images (upload_listing_image, upload_profile_image)
  • listings (add_image, close, create, open, query, query_own, search, show, update)
  • marketplace (show)
  • messages (query, send)
  • own_listings (add_image, close, create, open, query, show, update)
  • password_reset (request, reset)
  • reviews (query, show)
  • transactions (initiate, initiate_speculative, query, show, transition, transition_speculative)
  • users (show)

Also, seems that Flex API has very relaxed data model about listings and user profiles (and probably transactions and bookings also), more like schemaless document-oriented structures, not plain sql table based, so you define any custom fields, attributes, categories, options, and forms just in your components code, not by switching some admin config toggles or database migrations.

3 Likes

Well that is some pretty clever reverse engineering! :smiley::+1:

Hey there,

Received the communication about Sharetribe Flex and not sure of the details of how it works.
Is this another layer of services that will be provided by Sharetribe Ltd. for hosted clients only?
Will open source users get the new APIs and layout (ST layout is changed) in a 7.4.0 version?

When looking at the sites (Swimmy, Studiotime…) featured in the communication, I noticed that the search function is now solely a Location-based search? Can there be a combination of key word / location search like in the previous version? Will the location search be released in open source (finally)?

What are the main impacts for open source Admins willing to upgrade to the new UI and features in the future?

Thanks

Hi,

Our existing Sharetribe product, now called Sharetribe Go, and the second product, Sharetribe Flex, are separate products. In other words, Flex will have no impact on Go’s features, capabilities or support. We are a two product company. Naturally, creating an easy migration path from Go to Flex is on our agenda when we get a little further.

At the moment Flex is in closed preview mode. Going forward, we will be adding more features to it, incrementally accept more people to the preview program and will share much more, and more detailed information, about Flex. If you’re interested to be the first to hear more, do sign up at https://www.sharetribe.com/flex/. We will be building this product in close collaboration with our audience.

Thanks.

Is Sharetribe Flex an open source code as well? Or Sharetribe Ltd’s Intellectual Property?

Thanks

I’m afraid, only Sharetribe Flex SDK could be opensourced eventually, probably not before 1-2 years from now, but the implementation of backend parts (API and administration) will never be.

For example, there are references to services that are used in hosted Sharetribe Go internally, but not publicly available:

  • Harmony (Clojure) - booking availablity management, opensourced but not updated
  • Zappy (Clojure) - search engine powered by Elasticsearch and streamed mysql logs for indexing
  • Discovery (Clojure + React SearchPage) - experimental, seems to be now superceded by Flex

Those services need some very specific setup and deployment environments (like running a set of dependent dockerized containers, configured external services), and have clearly understandable reasons to not publish something that is unusable without major support from core team.

Sharetribe source code already expressed overall intent to move to a set of API-based services and single-page application, making it sometimes more complex with additional layers (like app/XXX_service/api, app/XXX_service/store), but that transition was never finalized, and now it is clear why.

So, the Sharetribe Flex was created ground up based on solid real experience and customer needs, partially reusing some solutions from existing parts.

One note about extensions - as the Flex applications are client-side only, to securely integrate with own api services that need calls on behalf of user, one way would be to pass JWT auth token to extension api request, and then verify with Flex API, or just intercept login process sending password to own server, maybe.

And for admins, I think, there is extended api (and maybe support for webhooks later), so one can create own-hosted background services calling admin API directly, for example to send reminders, newsletters, or prepare monthly reports etc.

3 Likes

That’s a very good analysis. I’ll clarify couple of things still.

Sharetribe Go and Sharetribe Flex take very different approaches architecturally. We are intentionally making different tradeoffs with the design of Flex. Go is a Rails monolith and as such suitable for on-prem deployments. That’s why it also makes sense to make it Open Source and allow people to build their own customized forks of Go that they then host themselves. The downside with this approach is that with Go everything is tightly coupled; the backend implementation, data model and user interface. This makes modifying the user experience and the ordering flow of the marketplace implementation quite laborious, especially when you move further away from the out-of-the box experience.

Flex, on the other hand, is built from ground up as a set of components that integrate via APIs. The user interface for customers and providers is deployed per marketplace. This makes it almost trivial to match your own branding and user needs. You can also very easily integrate things like web analytics (GA, Kissmetrics, …) or messaging (e.g. Intercom) to the UI. To get started with building the UI, we provide an open source template application that is based on JS, React and Node. JS SDK, also open source, is provided to make communicating with the API services easier. We will open both components still during this year.

Internally, the implementation of the API services is what you might call cloud native. Today, we’re targeting AWS and taking advantage of many of the AWS proprietary components there such as DynamoDB, Elastic Container Service, caching and search as well as other services outside AWS like image processing and transactional email. We provide the combined power to marketplace implementations via our managed, hosted APIs. The exact implementation will continue to evolve and change behind the scenes but we will be maintaining a backwards compatible API.

These choices mean that Flex API services is not suitable for on-prem deployments. This in turn means that, unlike with Go, the mechanism for extending and customizing is not one where you fork the implementation. Instead, we will build and provide other means to plug into the backend and extend it’s capabilities. Extended API will be one such mechanism. Webhooks and single sign-on support are also on the roadmap. We’ll know and share more as we get further.

We’ve changed our plans and approach over the past 2 years. The initial idea was to morph Go into something like what Flex is today. That path proved to be too slow and to have too many difficult compromises between providing and on-prem version and an API based one. I firmly believe that the strategy of having two separate products to serve two different use cases coupled with a migration path from Go to Flex, will offer the best of both worlds.

5 Likes

So does this mean that Sharetribe Go can move back towards a simple more pure Rails Monolith and drop some of the separate services such as Harmony, Zappy and Discovery?

Thanks for the great analysis zenik and thanks for all the clarifications ovan.

For what it’s worth I agree ovan that the strategy makes a lot of sense between Go and Flex. Two different purposes, addressing different degrees of maturity.

We may consider migrating to Flex as we mature our roadmap. There will be few questions, such as “Does Flex allow keyword and location searches combined?” (the current examples only feature location search)… but Flex seems really interesting when we have gathered more UX feedback and want to provide more specific features.

Thanks and good job!

The Github’s FLEX.MD is filled with “Try it out”, setup documents etc.? but nothing is working, ultimately requiring an SDKclientid: Can I mess with the front end at all? Make a mock demo, or get a head start before you open it up the full API to the public? I know the guts will not work, but running it on my localhost I get this error.

Thanks for reporting! Indeed Flex is an API-based product and a key is required to enjoy all its feature.

Did you request access already at https://www.sharetribe.com/flex/?

Keep us posted!

haha, Yes thank you, I sent an initial request to see if I can use flex. and the automated response was that our project wasn’t a fit. blah blah. However yesterday I saw another less obvious link. to request an API Key. so yup I have one. :). where can I see my limitations? for example, the only type of marketplace built is a service/rental type. Our project calls for a product-centric marketplace and the only thing I see becoming a major issue, is the search bar. For the location in our project is a secondary concern. I Really enjoy the new Views and layout would much like to spin it up for our MVP. I’m combing through the documentation it’s great. took me a while to find the (en. file)( didn’t know that’s how I change the text etc lol) as I am new to this file structure and React.js in general. So Key Questions:

  1. How difficult might it be too add additional functionality to make Flex, Product-Centric / like quiver with possible dual search fields, based on the product’s name/type not only the location?

  2. What is the current limitation with the API, and how far can one go independently? I haven’t gone deep enough to start building Extended listing functionality. Is it worth doing at this stage? for someone that isn’t working hand in hand with Sharetribe? thanks

Indeed, this new link was added very recently, good to hear that you are testing things.

Indeed, Sharetribe Flex focus is strongly on Service and Rental marketplaces. For example, there is no support for a shopping cart, a shipping feature or advanced invoicing, some things that are often key in a Product marketplace. We may add this in the future but it’s unlikely to happen in the coming year. For your marketplace idea, Sharetribe Flex may not be a good fit, unfortunately.

At present, a location search is available however a keyword search is not possible yet. We’ll probably add this in the coming months though. You can still build your own filters using Extended Data though.

With all the features, Extended Data and more, there’s a lot you can build! And because you control the front-end entirely, you can even build your own back-end for a small specific feature addition if needed. Can you share a bit more details about the limitations you have in mind?

Finally don’t hesitate to contact us at flex-support@sharetribe.com or join the Slack channel for Flex developers to discuss with others about their own work and customization!