Attendees

Agenda

• Review of SIG Goals
• Database Segregation
• API logs 
• Agenda for next meeting

Materials

Meeting Notes

• Review of SIG Goals
• Discuss Database Segregation
  •  Review of current model & challenges with current routing
    • 
    • 
  • Instructure
    • Main reason for deploying to different modes is for partitioning, so you don’t need to stand up another API instance but still able to maintain admin database so this the same as having one deployment mode and each service deploying assuming you can share the admin database/different target  databases with partitions and a shared instance could be a specific year instance 
    • Vinaya - Yes idea is to allow that while simplifying configuring them with one deployment mode
  • Flexible Route 
    • Route will always include route_aprt1/route_part2 sections that are configurable
    • Instructure - My API server URL with school year ID - really only 1 deployment; our current deployment is very similar but we use subdomain rather than path and it comes before 
    • Vinaya - shared instance will be covered, hoping sandbox instance can be included as well.
  • Flexible Segregation
    • 
    • Route/string is flexible - slide shows year specific example - see PPT for additional examples
    • Education Analytics - connection strings stored in config file, if not using trusted credential would it need to be included in the mapping?
      • Vinaya - current stored in app setting so it’s visible
        • Key value store or database would be better
      • Stephen - one option is to store in SQL server (details not figured out yet), but do not want to force to have another database configuration
        • Connection string on the same server
    • Instructure - It would be helpful if connection string can be customized
    • Vinaya - Yes, the goal is to have connection string configuration to be flexible
    • EdWire - If we do have the mapping we will need to create the mapping ahead of time - there is no longer a place holder for connection string. Each request will reach out to that value so caching must be close to the server.
      • Vinaya - Yes, if you add another district, API restart may be needed or some way to refresh the cache.
      • EdWire - like the idea and think it’s on the right track
        • Can number route parts be flexible 0 to 2? 
        • Vinaya - not sure but with routeparts being flexible it becomes less defined in the code logic - will need to look at this 
      • Instructure
        • I think routing and declaring variables should be flexible...letting configuration determine - see URL below 
        • Example Routing options: 
          • https://<InstanceId>.ed-fi.org/<SchoolYear>/data/v3/
          • https://api.ed-fi.org/<InstanceId>/<SchoolYear>/data/v3/
        • Stephen - we have more limitations and this may be a practical challenge but can take a closer look; could a load balancer gateway be a sub domain and be put in the internal route
        • Instructure - would not want to modify existing work; what is the API this client is using; may need to be done by suppliers rather than Ed-Fi?
        • Vinaya - Our deployment shows version number, but that is not built into the API code it is rather a deployment setting;
          • Stephen - in Meadowlark will be a stage change, will be harder but not impossible to add that feature, needs more discussion - more code to add school year after API
        • Discussion of having data standard version in URL
          • Wisconsin - We take minor releases and would be a lot of work with districts on their configurations
      • Keen Logic - Can the API version be decoupled from the data standard?
        • Vinaya - future work is moving ahead to decouple API versions from data standard versions; API will be released at the latest version of the API code and a specific data standard version; API code will be decouple in such a way to hold multiple data standards
• Participants shared new feature ideas
  • Keen Logic - ways to get more information JSON payload
    • NEFEC has built a log system based on IIS, different from the cloud
      • Client IP  APP response
      • Endpoint URL
      • Can capture count
  • Would be able to do a quick check if SIS could be failing for a particular vendor - would then notify the district what was failing - not always readily picked up and would like checks with each client - can this be a core API log?? 
    • Instructure does not have this solved
    • Education Analytics -We have all of that information in nginx logs
    • Keen Logic - would like this as core offering of Ed-Fi
    • EdWire - some are in own product but within log are able to provide links - not exposed or for internal  
      • Do not want those logs exposed to public 
      • Want to make sure those logs are filtered to individual customers
• Ideas for future topics:
  • Recently put in ticket adding the ability to separate read requests; how to add a read replica connection string
  • Service providers to share more about our implementations and infrastructure deployments

Next Meeting08 Dec 2022