clovellytech / http4s-modules Goto Github PK

Lots of opportunities to log helpful messages.

Testing should have a client implementation available, and define properties to submit tests

For example:

1. User signup
2. User login
3. User posts feature
4. User cannot upvote feature

Ex 2:

1. User login
2. User gets list of features
3. User upvotes feature with comment
4. User gets list of features - verify vote in feature

We should make it easy to access the endpoints via scalajs.

Make it easy to add validation to user inputs.

• Auth:
  • Assume usernames are email addresses, validate them.

Migrating modules requires listing every necessary module by name, for example, if one wants the feature-requests module and the auth module, one must initialize via:

DatabaseConfig.initialize(config)("ct_auth", "ct_feature_requests")

ct_feature_requests requires the ct_auth module to exist first. So there should be a better way to encode this dependency, and remove the strings.

Those strings also have to be exactly those, as the initialize method is going to look in resources for s"db/$schemaName/migration" This is a string then that the module owns and should not need to be specified by the user.

At the moment bearer token authentication is the only authentication strategy available. We should enable users to specify other strategies, such as:

• ⬜️ JWT
• ⬜️ Basic

And do it in a way that reuses endpoint code.

All modules at this stage use Postgres UUIDs as primary keys. Not all users will want this, as it adds a small amount of storage overhead, and might impact the way that postgres builds indexes.

So if there could be a way to allow the user to configure these and use sequences or whatever else for modules that already exist, that would be good. Or, we should just plant our flag and document the reasoning for using UUIDs for all the primary keys.

All modules come with SQL table definitions and default implementations for endpoints and database connections, so it should be possible to generate a complete running project given only a selection of modules.

Flyway throws out a ton of verbose logging, and our case is extreme because we apply migrations rather repetitively.

All these INFO lines are not valuable in CI/testing, so they should go away.

[ioapp-compute-0] INFO  o.f.c.i.d.DatabaseFactory - Database: jdbc:postgresql://127.0.0.1:5432/ct_h4sm_root (PostgreSQL 9.6) 

[ioapp-compute-0] INFO  o.f.c.i.d.b.Schema - Creating schema "ct_files" ... 

[ioapp-compute-0] INFO  o.f.c.i.s.JdbcTableSchemaHistory - Creating Schema History table "ct_files"."flyway_schema_history" ... 

Assume usernames are email addresses, track verification.

All our dependencies are on 2.13 now, no reason we can't publish on both 2.12 and 2.13.

If we run the server as:

> exampleServerJVM/reStart

Then run the scala-js tests from command line:

> authClientJS/test
[info] - should be in test
[info] - should allow login after signup *** FAILED ***
[info]   org.scalajs.dom.ext.AjaxException:
[info]   at $c_Lorg_scalajs_dom_ext_AjaxException.$c_jl_Throwable.fillInStackTrace__jl_Throwable(file:///home/projects/clovellytech/oss/http4s-modules/modules/auth/client/js/target/scala-2.12/scalajs-bundler/test/auth-client-test-fastopt-bundle.js:33055:14)
[info]   at $c_Lorg_scalajs_dom_ext_AjaxException.$c_jl_Throwable.init___T__jl_Throwable__Z__Z(file:///home/projects/clovellytech/oss/http4s-modules/modules/auth/client/js/target/scala-2.12/scalajs-bundler/test/auth-client-test-fastopt-bundle.js:33173:10)
[info]   at org.scalajs.dom.ext.AjaxException.<init>(file:///home/projects/clovellytech/oss/http4s-modules/modules/auth/client/js/target/scala-2.12/scalajs-bundler/test/auth-client-test-fastopt-bundle.js:77908:58)
[info]   at org.scalajs.dom.ext.Ajax$.org$scalajs$dom$ext$Ajax$$$anonfun$apply$1(file:///home/projects/clovellytech/oss/http4s-modules/modules/auth/client/js/target/scala-2.12/scalajs-bundler/test/auth-client-test-fastopt-bundle.js:7584:63)
[info]   at XMLHttpRequest.onreadystatechange(file:///home/projects/clovellytech/oss/http4s-modules/modules/auth/client/js/target/scala-2.12/scalajs-bundler/test/auth-client-test-fastopt-bundle.js:7596:46)
[info]   at XMLHttpRequest.callback.(anonymous function) (/home/projects/clovellytech/oss/http4s-modules/modules/auth/client/js/target/scalajs-bundler-jsdom/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:289:32)(Unknown Source)
[info]   at invokeEventListeners(/home/projects/clovellytech/oss/http4s-modules/modules/auth/client/js/target/scalajs-bundler-jsdom/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:219:27)
[info]   at invokeInlineListeners(/home/projects/clovellytech/oss/http4s-modules/modules/auth/client/js/target/scalajs-bundler-jsdom/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:166:7)
[info]   at EventTargetImpl._dispatch(/home/projects/clovellytech/oss/http4s-modules/modules/auth/client/js/target/scalajs-bundler-jsdom/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:122:7)
[info]   at EventTargetImpl.dispatchEvent(/home/projects/clovellytech/oss/http4s-modules/modules/auth/client/js/target/scalajs-bundler-jsdom/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:87:17)
[info]   ..

The same tests will pass using > authClientJS/testHtmlFastOpt:

Note you have to edit the resulting html test file, to include a different js file, as:

<script type="text/javascript" src="scalajs-bundler/test/auth-client-test-fastopt-bundle.js"></script>

The authentication in these tests relies on bearer token authentication. I've found that in the node backend the headers are just not available at the time that they should be, in the map call here: https://github.com/clovellytech/http4s-modules/blob/b605ad0/modules/common/js/src/main/scala/h4sm/common/AjaxAPI.scala#L50

CRUDAlgebra includes two update methods, safeUpdate and update. safeUpdate is meant to handle updates where an ID is known, and update is meant to update the fields based on whatever fields are in the update method.

Every UAlgebra implementer can update based on ID, but not all can update without an id, as not all data models will contain unique fields. Thus we should treat update without an id as a special case that should be added by extension by users of UAlgebra.