One of the first steps a new user takes when joining Golioth is to create a “Project”. But it’s not always clear why you would have one project over another. I’m going to give some guidance on how you might want to set up your projects in your Golioth account.
What are your project needs?
Trial
The Golioth Dev Tier only has access to create a single project. This means all 50 of your devices you can put onto the platform for free will be in the same project by default. If you’d like to up the number of projects you can create, please contact our sales team. We think that for testing out Golioth, this works great! You’re likely working with many of the same type of device, which works well. If you have more than one type of device, you can segment them by using Tags or Blueprints, as well.
Product Shops
Companies that develop and sell their own projects will likely want to break down their Projects by their product families. If an IoT company makes a dog tracker and a refrigeration monitor (“is your refrigerator running?”), they would likely want to create two different projects, even if the underlying hardware is very similar.
If say the dog tracker has multiple hardware revisions, including different chipsets or sensors on board, that likely makes sense to track using Blueprints. You can use Blueprints to build targeted Over-the-air (OTA) Firmware updates, so you make sure your update is only going to the devices that need it.
From a data export perspective, using something like Output Streams, it’s likely that you would want each Project to be pointing at different services. The Dog Tracker might be using AWS, but the Fridge tracker was built when your company switched over to Azure. It’s possible for each project to define their own output streams.
Dev Shops
Development (Dev) Shops often service multiple Clients. This is a very clear case where you want to separate the work of Client A from Client B by Projects. There is no data sharing between projects, so you can feel comfortable having them in the same place, while also conveniently being able to switch between Client projects as needed.
If a Client has multiple products you are developing, you can name your projects to match, something like “Client A - Dog Tracker” and “Client A - Fridge Tracker”.
Furthermore, with Project roles, you can invite your clients to each project individually and have a “master view” of all projects that your dev shop is working on.
As of right now, there is no way to hide information on the console from one client over another. If you were showing your client the “master view” of all projects (ie. your account owns all the projects and you have visibility of every project your company is working on), they will see the names of your other clients when looking at the Project page. We recommend only showing them data through a “shared project” view (ie. look at the Console of someone who has only been added to a company’s specific project). You may also want to have one main account for your Dev Shop that is centrally controlled by an admin, and employees working on projects are sent a shared link on an as-needed basis.
If client separation is a particular concern, implementing a code system for your various clients in order to do basic data hiding. You can also reach out to the Sales team for more tips and tricks on using your account in an effective way.