tomfa / booking-service Goto Github PK

api.vailable.eu

Given a token, what's my customerId? userId? issuer?

Booking multiple rooms at once should be a possibility.

Creating a schedule is quite cumbersome.
Make it easier? Yes.

Disabled resources should not be returned unless explicitly asked for.

I bet there is no problem adding negative length slots or resources with opening hours that are strings outside the intended format.

Case:

• There are 12 project areas (7m2 each). They are physically grouped as 2 + 4 + 4 + 2.
• People want to book them. Maybe right now, maybe later. Maybe for a day, maybe for a month
• People might want to book 1 area, or 3 or 6. They would probably be displeased if they booked 2 areas, and got them at each side of the room instead of in a group.
• A group of these want to book now.

Thoughts:

• We need a quick UI to solve this case.
• We probably don't want to programatically choose areas – some are probably OK with separate areas, some might even want it.
• This could be the basis of an example for how to display a calendar with booking?

Solution?:

• This is 1 resource with 12 seats, not 12 resources with same category.
• ...which means you must be able to book a specific seat, and see availability for seats.
• Create an SVG with rectangles representing each room.
• Immediately display availability (on the SVG) right now today (for the next increment of time)
• A calendar above the Availability (Current month) has red / green color for each day there is availability.
• Allow user to filter availability by setting number of required project areas + booking length (number of consequtive slots)

Fix shared package. Then add new package vailable-auth with help methods for creating tokens, with autocomplete for permissions.

import auth from 'vailable-auth';

const userToken = auth.createToken({ 
  secretKey: string, 
  accountId: string, 
  userId: string,
  permissions: Permission[] = ['vailable:role:user'], 
});
const adminToken = auth.createAdminToken({ secretKey: string, accountId: string });

Migrations are manually in production. Make them automatically run on deploy?

How coujld that be the default?

https://www.npmjs.com/package/firestore-jest-mock ?

The code is a copy-paste from github.com/tomfa/pdf-generator-api/.

Rename everything to booking-service

Use same pattern as e.g. Sentry.

import Vailable from 'vailable';

// Instead of 
const api = new Vailable({ ... });
api.findResources();

// Do
Vailable.login({ username, password});  // Only require to be run somewhere in the application first
// Alternatively
Valiable.authenticate({ token });

Vailable.isAuthenticated() // true/false
Vailable.findResources();

We can do this by storing auth outside the class instance as a default fallback if class itself does not have auth + making all methods static (can static methods use this?) – By keeping the class we can then also allow user to make multiple instances of a client for different users (low pri, I'm unsure of the usecase, but there probably is one)

Required fields in JWT

• sub: userId
• iss: url specific to account. E.g. https://api.externaluserhomepage.com
• exp: Unix timestamp / 1000. E.g. 1577836800 for 2020-01-01T00:00:00Z
• www.vailable.eu: JSON object containing account and permissions.

{
  "sub": "1312",
  "iss": "https://YOUR_DOMAIN",
  "exp": 1577836800,
  "www.vailable.eu": {
    "account": "vailable-account-userid",
    "permissions": [
      "admin/*",  // allows everything
      "user/*",  // allows booking management on behalf of -all- users
      "user/1312/*. // allows booking management on behalf of user "1312",
    ]
  }
}

The issuer must expose well known jwks at https://YOUR_DOMAIN/.well-known/jwks.json, see https://docs.cidaas.com/standard-endpoints/server-jwk-set.html#31-well-knownjwksjson

Resource should be able to have category field added. E.g. DESK. Free text.

• When querying availability, add option to filter by resource category.
• When finding Resources, add option to filter by resource category.
• When finding Bookings, add option to filter by resource category.

Schedule is returned from with 00:00 -> 00:00 as closed. This doesn't quite work.

We should add an isClosed or set start/end time to empty string when things are closed?

FindAvailability should return a list of available seatIds.

• Allow creating client without api key
• Set API key when .login() on sdk is called

Need a quick and dirty sdk for development to start on related projects that will use this service.

Can store in-memory, and not handle authentication. This is just for testing/developing.

• Add commitizen
• Add semantic-release
• Extracts SDK to own app
• Deploy to npm when sdk is updated

When creating a booking, you must specify start and end.

Instead, allow specifying start and lengthMinutes.

Get this deployed at a domain. web + api.

Github actions should autodeploy when changes are made to master. No need for a staging environment (yet anyway)

JWT should be allowed to be used without an active issuer endpoint, by setting public key in Customer database.

For a user with admin priviliges (e.g. on an API), we should be able to call sdk.createUserToken(userID: string, audience?: string, customPriviliges?: string[]) to generate a user token.

Fucking tslib.

__spreadArray is not a function.

Why? Wrong tslib version. Why was there a wrong tslib version? Because I haven't added tslib to my sdk dependencies? Probably?

Using babel to compile typescript is also an alternative: https://ricostacruz.com/til/babel-typescript

No sub-entities are exposed. Maybe they should?

• with a GraphIQL interface

Say for a party, you could have access to the party or not. No slot duration, interval and only 1 date.

Case: Room A is open (CEST) from 08-16 on Thursday, and 00-00 (all day) Friday.

Adjusted for timezones, this is 06-14 + 22-00 Thursday + 00-22 Friday CEST.

This is not supported by the way we store Schedule in database, where one day cannot have multiple opening hours, nor in the SDK (getResource) where the same is the case.

Short term solution (CEST)

• call addResource with UTC times.
• avoid consuming Resource.schedule.
• No CEST resource can open before (02)

Medium term solution:

• Instead of start + end in Schedule, generate an array of start + end. The case above would for Thursday store [{start: 06, end: 14 }, { start: 22, end: 00 }]
• Add timezoneoffset as argument to sdk, which will map any incoming and outgoing references to the clock. It can use new Date().getTimezoneOffset() as default.

Additional DST timezones fix:
For summertime vs wintertime, we want the schedule itself to "jump", 1 hour back and forth wrt. UTC, not just in display.

We can implement a getResourceOffset function in the api, that adds or subtracts to the schedule before exposing it through GraphQL. This would require a timezone field to be added to the Resource.

To know for sure what the time represents, we can store a timezone along with the resource (this way, 1 customer can have resources in different timezones).

• Seat id should be added to Booking.
• Seat id should be a number from 1 -> resource.seats

(Later stage: specify meta info per seat? Now there will be a problem if one reduces the number of seats?)

usecase: admin should be able to reserve x seats for x amount of time for a special project